httpwg
resumable: introduce new append-granularity limit
@danielresnick There should be an exception for the size of the final chunk at the end of the file.
Requiring upload-complete be set for the final chunk would take away the ability of a robust client to send chunks, and then separately without any additional body content, to send Upload-Complete. The ability to send a separate message separates the uploading from marking the upload as complete.
The authors of resumable uploads have made many premature optimizations and I hope that they do not downplay or ignore the robustness of separation of concerns when evaluating this append-granularity feature.
Personally, I would prefer that the granularity be a hint, and not a hard error, especially since according to the resumable uploads draft, a server may accept part of an upload even if the upload gets disconnected. If there was a part of the granularity chunk committed and the offset is no longer a multiple of the granularity, then a client might wish to send a smaller chunk (smaller than the granularity) even in the middle of an upload in order to re-align with the granularity for further chunks.
Thanks for the feedback @gstrauss. Just to make sure I'm understanding, you're suggesting that the proposed carve out for final chunks ("Requests completing the upload by including the Upload-Complete: ?1 header field are exempt from this limit.") be generalised to not necessarily require Upload-Complete: ?1, but rather be applicable to any append request which would result in the reaching of the declared Upload-Length (if there is one), is that right? If so I'm open to this idea, though am interested in others' thoughts also. It's definitely more difficult to express concisely, but I can see how it might improve separation of concepts.
Re: hint vs hard error, as I mentioned on https://github.com/httpwg/http-extensions/issues/3193 I'm open to expressing this as SHOULD rather than MUST, but I do think it's important to be clear that a client intending to be widely interoperable with a variety of servers needs to be aware/respectful of potential granularity requirements.
Re: "a server may accept part of an upload even if the upload gets disconnected", I think the onus should be on the server which is advertising an append-granularity to avoid committing partial state that isn't aligned with that granularity. In fact the whole motivation for append-granularity's existence is server-side limitations that make it technically difficult to commit on non-aligned boundaries. Or to put it another way: clients shouldn't need to worry about re-aligning granularity. Open to suggestions on how I might make this clearer in the PR! Thanks again for the detailed feedback!
Thank you for this proposal! We'll bring up the general topic of handling granularities during the IETF 124 httpbis meeting next Wednesday.
Noting before I forget: assuming I understood @gstrauss 's feedback correctly I think min-append-size also has this discrepancy as-is, so we should aim to be consistent for both. That is either only exempt requests with Upload-Complete:?1 from the limit, or exempt any request which contains the final bytes of the representation data as indicated by Upload-Length (in the current or a previous request).