Need to consider the Expect header

[LPardue]

Draft 00 doesn't mention the Expect header at all. I think we might find some rough edges here depending on how the feature discussion settles. The final answer might boil down to a reference to Expect and 100 (Continue) responses.

A more complicated answer might have to address potential conflicts between 100 and 104 status. Imagine a vanilla client that POSTs with Expect: 100-continue and a server that responds with 100 Continue. Would a resumable upload client send Expect? And if so, is there any ordering requirement on the 100 and 104 resonses?

Or maybe a client could send an Expect: 104-upload-resumption-support (if we defined that token) - and then we'd have to list out the requirements about handling it. But then that seems in conflict with the design goals of this draft to seemlessly switch.

[Acconut]

I like the idea of having an Expect: 104-upload-resumption-support header as it indicates the client's intention of using resumable uploads, if available.

On the other hand, this might also cause issues with existing server, which do not understand this header. This could also lead to problems as you referring to possible conflicts between 100 and 104.

[martinthomson]

Given the very narrow definition of Expect in older specifications[^1], I suspect that there will be teething issues arising from use of any expectation for this - at best. It's something you might do once you verify that a resource on that server supports resumptions, but not universally.

[^1]: RFC 7231 defines it as just Expect = "100-continue", even if RFC 9110 attempts to have it conform to token syntax.

[reschke]

Maybe the Prefer header field would be more useful here.

[LPardue]

Prefer sounds reasonable if we want to send anything at all

[Acconut]

Maybe the Prefer header field would be more useful here.

That is a good point, yes. The Prefer and Preference-Applied headers (https://datatracker.ietf.org/doc/html/rfc7240) to seem like a good approach to let the client indicate interested in upgrading to a resumable upload.

[Acconut]

A more complicated answer might have to address potential conflicts between 100 and 104 status. Imagine a vanilla client that POSTs with Expect: 100-continue and a server that responds with 100 Continue. Would a resumable upload client send Expect? And if so, is there any ordering requirement on the 100 and 104 resonses?

I currently seems like we will not have a Expect: 104-upload-resumption-support as Prefer or another header are better options. As such, a client could still send Expect: 100-continue in the Upload Creation Procedure or Upload Appending Procedure. I do not see a problem with incompatibility here.

For the Upload Creation Procedure we should be a bit cautious:

• The server should only send the 104 informational response if the client indicates its interest in resumable uploads (e.g. using the Prefer header)
• If Expect: 100-continue is present in the response and the server sees interest from the client, the server should first send an 100 Continue before 104 Resumption Supported. Just to avoid issues with proxies or other intermediary parties.

[Acconut]

The use of Perfer for request identification is tracked in #2295. There seems to be many reasons against Expect: 104-upload-resumption-support for identifying resumable uploads.

The Expect: 100-continue header can be used with the resumable uploads draft without complications. Considering this, should we explicitly mention this compatibility or leave this out of the document?

[Acconut]

It does not seem like there is a need for mentioning Expect explicitly right now.