RESUMABLE: Describe GET request against upload resource

[Acconut]

Closes #3214.

This PR updates the document so GET requests are to be handled as HEAD requests. It's explicitly mentioned that no requirements on GET response content is placed:

This document does not place any requirements on the response content for GET requests. In particular, the server is not required to respond with the transferred representation data.

Let me know if that's not needed.

[Acconut]

Thank you for your the reviews, Grant and Lucas!

[smatsson]

You guys are way too quick for me, please slow down a bit! :P

I think this change brings some potentially unwanted situations. Before I go into it, I do understand why this was added, but I'm not sure it really aligns with the definition in RFC 9110 anyway.

If we look at GET under RFC 9110, it states: "The GET method requests transfer of a current selected representation for the target resource." The representation of the target resource in this case is the uploaded data itself. Redefining what GET returns in this PR is, in my opinion, just as problematic as changing the definition (i.e., splitting) HEAD and GET, as was done previously.

From an implementation standpoint, the server code handling uploads would now also have to support/intercept GET. Since it is only RECOMMENDED that the client uses HEAD, there is a real risk that clients will actually use GET just to fetch the upload status/offset.

In many implementations, the upload handling is built as a middleware that intercepts the upload flow, while simply passing along requests it shouldn't handle (like GET requests for downloading the data) to the underlying application. This means we are now implicitly dictating that a server cannot offer file downloads on the exact same URL where the upload takes place, without turning the code into spaghetti where the middleware has to intercept and rewrite responses from the user code.

The alternative is that the middleware always responds with the full file data, but then there's a huge risk of transferring massive amounts of data back to a client that only intended to check the offset (again, because the client CAN use GET without a real reason).

At the beginning of this draft process, when we had the concept of the client creating a token, we received criticism because we were dictating how/where the server should structure its resources. I feel that this change introduces the exact same problem.

[Acconut]

If we look at GET under RFC 9110, it states: "The GET method requests transfer of a current selected representation for the target resource." The representation of the target resource in this case is the uploaded data itself. Redefining what GET returns in this PR is, in my opinion, just as problematic as changing the definition (i.e., splitting) HEAD and GET, as was done previously.

This is not entirely correct. The representation of the upload resource does not have to be the representation that is uploaded. It can be (if that's the purpose of the server), but it can also just be an empty representation (what this draft aims at), a textual description of the upload progress or anything else. There is no text in RFC 9110 or this draft that requires a GET request to return what was previously uploaded and the server can choose what representation to serve.

In many implementations, the upload handling is built as a middleware that intercepts the upload flow, while simply passing along requests it shouldn't handle (like GET requests for downloading the data) to the underlying application. This means we are now implicitly dictating that a server cannot offer file downloads on the exact same URL where the upload takes place, without turning the code into spaghetti where the middleware has to intercept and rewrite responses from the user code.

A middleware implementation is still able to pass the GET request to the origin server, as long as it adds the necessary Upload-* header fields to the response. This is how reverse proxies operate and shouldn't be an uncommon mode of operation in HTTP deployment. This normative change doesn't prevent origins from handling GET request against the upload resource in their own, custom ways.

Does that clear things up a bit for you?

[smatsson]

I don't agree with any of what you just said but since this is already merged and you decided that it's correct I'm not going to argue.

My point still stands; since this change allows the client to use GET to retrieve the offset, the server can in practice no longer use the same URL as the download URL as the client might call this URL multiple times during upload and thus re-download the same data over and over again.

[GrantGryczan]

I don't have a strong opinion one way or another here, but if you do then I believe it is undoubtedly worth discussing. Things can always be changed! :)

It is recommended for clients to use HEAD, so I find it most likely performance wouldn't be an issue in practice. If the problem is mainly that you don't want to make the server deal with repeatedly sending the incomplete representation data for every offset retrieval from such a careless client, would it suffice just to change the recommendation for clients to use HEAD to a requirement? If not, I'm not sure what alternative you mean to propose.

As for the other server burden you mention, RFC 9110 already recommends that HEAD responses return the same headers as GET responses to the same resource, so realistically, I suspect servers would already want to support GET with these headers regardless, no?

[smatsson]

It is recommended for clients to use HEAD, so I find it most likely performance wouldn't be an issue in practice. If the problem is mainly that you don't want to make the server deal with repeatedly sending the incomplete representation data for every offset retrieval from such a careless client, would it suffice just to change the recommendation for clients to use HEAD to a requirement? If not, I'm not sure what alternative you mean to propose.

The core issue with keeping it as a "recommendation" is that server implementers still have to build support for GET during the upload phase to account for clients that don't follow the recommendation.

This leaves servers with two choices:

1. Return the body upon GET just to deliver the offset headers, which is a significant waste of bandwidth (and honestly no proper implementation will do this)
2. Disallow file downloads entirely on the upload URL.

While option 2 isn't a problem for simple one-off form submissions, many systems in the wild (like those running tus today) keep the upload URL around permanently as the actual URI of the file (similar to Dropbox folders). If the server has to intercept GET to serve upload offsets, it becomes very difficult to serve the actual file download on that same URL without adding a lot of architectural complexity to separate the two states.

So yes, your suggestion to change the recommendation to a strict requirement (MUST use HEAD to check upload status, leaving GET undefined by this spec) would absolutely solve this problem and remove the burden from the servers.

As for the other server burden you mention, RFC 9110 already recommends that HEAD responses return the same headers as GET responses to the same resource, so realistically, I suspect servers would already want to support GET with these headers regardless, no?

In my practical experience with these types of systems, this isn't typically how they are architected. Most implementations I've seen handle HEAD exclusively to manage the state machine during the upload phase (fetching the offset/status). GET is kept entirely separate and is strictly reserved for downloading or interacting with the final data/file. Blending upload-state headers into standard file retrieval GET responses isn't a common pattern in practice, which is why allowing GET to be co-opted for offset retrieval causes these architectural friction points.

As a minor process note: merging normative spec changes in under 16 hours makes it quite difficult for those of us in different time zones to participate in the review process before decisions are finalized. It would be great if we could leave PRs open a bit longer in the future to allow for async feedback!

[Acconut]

As a minor process note: merging normative spec changes in under 16 hours makes it quite difficult for those of us in different time zones to participate in the review process before decisions are finalized. It would be great if we could leave PRs open a bit longer in the future to allow for async feedback!

Thanks for the feedback! I'll keep the next PRs open longer to give more people the chance to chime in. That being said, the issue discussing this topic was opened 10 months ago and the proposed changes, which this PR just implements, were posted there 4 months ago. So this change not a particular new idea :) But I agree with you, that everyone should have time to comment on changes.

[GrantGryczan]

Regardless of the timeline, I think it would be wise to open a new issue challenging this change now. Late is better than never, and I am strongly opposed to the idea of leaving Stefan's argument unaddressed. Stefan always has great feedback.