RESUMABLE: Allow max-age limit to decrease as expected

[GrantGryczan]

Fixes #3395

[Acconut]

Thank you!

[GrantGryczan]

I added a min-size recommendation since it seems like it should be a more comprehensive list now, rather than some arbitrary examples like before.

[Acconut]

I added a min-size recommendation since it seems like it should be a more comprehensive list now, rather than some arbitrary examples like before.

min-size and max-size apply at the creation time of the upload resource. Changing its values after the resource has been created shouldn't affect the client's ability to complete the upload. Should we remove the mention of min-size and max-size from this paragraph, which talks about limit changes during the upload resource's timeline?

[GrantGryczan]

I believe it could affect the client's ability to complete the upload. If the client says Upload-Length: 100, and the server accepts that, but they later change their max-size to 50 or their min-size to 150, the client is recommended to cancel the upload. Alternatively, if the client knows the upload length will be within a certain range, but hasn't communicated an exact length, it may be unable to complete the upload if the required bounds for the upload length narrow.

[Acconut]

My previous comment isn't entirely correct because max-size can also be applied after the upload creation:

The server might also deactivate the upload resource if the offset (Section 4.1.1) exceeds the maximum size.

(from https://www.ietf.org/archive/id/draft-ietf-httpbis-resumable-upload-11.html#section-4.1.4-3.2.1)

Then let's keep this and get this PR merged!

[GrantGryczan]

Same for min-size, to be clear, since the min-size could be very large and may only be checked by the server upon the client communicating the length from an upload append request. Am I understanding correctly?

[Acconut]

The purpose of min-size is mainly to let the client know that the server won't offer resumable uploads for representations outside of those boundaries. But this doesn't mean the representation will be rejected when uploading via a traditional POST request, for example. A server may decide to only use resumable uploads for larger files as there is a cost of holding state involved for upload resources.

[GrantGryczan]

Oh, I didn't know that. That seems very worth clarifying in the draft. But also, I'm not confident in your explanation. It feels possibly partially conflated with min-append-size? Unsure. Let me open a new issue for this.

[Acconut]

The definitions of max-size and min-size state that the server might not create an upload resource if the indicated representation size falls outside of these boundaries:

max-size: Specifies a maximum size for the representation data, counted in bytes. The server might not create an upload resource if the length (Section 4.1.3) deduced from the upload creation request is larger than the maximum size. The server might also deactivate the upload resource if the offset (Section 4.1.1) exceeds the maximum size. The value is an Integer.

min-size: Specifies a minimum size for the representation data, counted in bytes. The server might not create an upload resource if the length (Section 4.1.3) deduced from the upload creation request is smaller than the minimum size or no length can be deduced at all. The value is an Integer.

It doesn't say that upload creation requests with sizes outside of these limits must be rejected. The server can still process the included representation without involving resumable uploads, which is a feature IMO, but a bug :)

[guoye-zhang]

Yeah, this is mainly to support optimistic discovery, the implementation should not reject uploads smaller than min or larger than max since the client might not know the limit ahead of time. If that's not a part of your use case, it's fine to be stricter.