Re: I-D Action: draft-ietf-httpbis-resumable-upload-08.txt

Hello Julian,

I started addressing your comments in two PRs [1][2], thank you again very
much!

I have a follow-up question regarding this point:

> 8. "Please note that the Content-Length header field cannot be used in
conjunction with the Transfer-Encoding header field." - really?

RFC 9112 Section 6.2 [3] stats the following, which I interpret as
Content-Length and Transfer-Encoding being mutually exclusive:

> A sender MUST NOT send a Content-Length header field in any message that
contains a Transfer-Encoding header field.

Am I missing something here? Is there use of Transfer-Encoding used outside
of HTTP/1.1 as well?

[1] https://github.com/httpwg/http-extensions/pull/3088
[2] https://github.com/httpwg/http-extensions/pull/3092
[3] https://www.rfc-editor.org/rfc/rfc9112.html#section-6.2-2

Best regards,
Marius

On Thu, May 1, 2025 at 2:26 PM Julian Reschke <julian.reschke@gmx.de> wrote:

> Am 11.04.2025 um 14:19 schrieb Julian Reschke:
> > Am 08.04.2025 um 14:14 schrieb Marius Kleidl:
> >> ...
> >> With the closure of https://github.com/httpwg/http-extensions/
> >> issues/2962 <https://github.com/httpwg/http-extensions/issues/2962>
> >> following the discussion at the IETF meeting, there are currently no
> >> more open issues for this document. Hence, we believe this draft is
> >> ready for a WGLC.
> >> ...
> >
> > +1 (and I'll try to review soonish)
> > ...
>
> Ok, not that soonish. But here's my feedback:
>
> Hi there,
>
> below a ton of nits, and a few more important things; sorry for the lack
> of structure.
>
> One big issue that I see is the overuse of BCP14 keywords.
>
> - for each MAY, please check whether this is actually an interop
> requierement or just a statement of fact. In which case "may" or "can"
> would be better.
>
> - for each SHOULD NOT, it's important to understand why this is MUST
> NOT. So what are the exceptional cases where not following the
> requirement is acceptable?
>
> I flagged some of these cases, but not all.
>
>
> 2. re STRUCTURE-FIELDS; maybe state here upfront that all fields defined
> here actually use that syntax; the definitions, for instance in 4.1.1
> are really not sufficient for readers not aware of SF to understand
> what's going on. Or, in each definition, link to the matching section in
> the SF spec
>
> 3.1 maybe say something about the PATCH media type early on?
>
> 4 But URIs of upload resources could be recycled, right?
>
> 4.1.1 "resource-loses" - typo?
>
> 4.1.3 "MAY use" -> "can use"
>
> 4.1.4 "MAY not create" -> "might not create" (twice)
>
> 4.1.4 "MAY stop" -> "can stop" - it does not need permission here, and
> it might choose to stop it for other reasons anyway.
>
> 4.1.4 "SHOULD NOT send such requests" - in which cases would it be
> allowed? Maybe this is a MUST?
>
> 4.1.4 "MAY make the upload resource" -> "might"
>
> 4.1.4 "client SHOULD NOT attempt" -> rephrase this as statement that
> such attempts will fail
>
> 4.1.4 "MAY be extended but SHOULD NOT be reduced" - unless?
>
> "under a target URI" -> "for a target URI"?
>
> "OPTIONS *" support is known for servers to be hard to implement, so a
> MUST feels out of place here.
>
> "The limits announced in an OPTIONS response SHOULD NOT be less
> restrictive than the limits applied to an upload once the upload
> resource has been created." - what about if the limit changes between
> the requests?
>
> 4.2.3 I would have moved that to an appendix (if only to avoid that
> section numbers will change later on).
>
> 4.2.4 Remove the version indicators before WG LC please.
>
> 4.3.1 "The client MUST NOT perform offset retrieval while creation
> (Section 4.2) or appending (Section 4.4) is in progress." - otherwise?
>
> 4.4.1 "The request content MAY be empty" - of course, why not? Why does
> this need permission?
>
> 4.4.2 "... and without discontinuities as possible." - what does this mean?
>
> 4.5.1 "The client MUST NOT initiate cancellation without the knowledge
> of server support." - how does it know that, and what would happen if it
> would do it anyway?
>
> 4.5.2 why does it need to be a 204?
>
> 4.6 "the resource SHOULD prevent race conditions, data loss, and
> corruption by terminating the previous request before processing the new
> request" - that actually sounds like a MUST.
>
> 5. "The start and end of the block might align with the start and end of
> the representation data, but they are not required to be aligned." -
> explain "aligned"
>
> 8. "Please note that the Content-Length header field cannot be used in
> conjunction with the Transfer-Encoding header field." - really?
>
> 9.1 " If the digests don't match, the server SHOULD consider the upload
> failed and not process the representation further." - and signal an
> error, right?
>
> 10. Can the "subsequent resource" have the same URI as the upload resource?
>
> 10. Content-Location appears to be incorrect here, see
> https://www.rfc-editor.org/rfc/rfc9110.html#section-6.4.2-5.5
>
> 11.1.1 What does "user" refer to here?
>
> 13. Split into subsections
>
> 13. The definition of Status Code 104 really needs a dedicated section
> that the registry can link to.
>
> 14.1 8792 does not seem to be normative, as it is only used in examples.
>
>
> Best regards, Julian
>
>