Content framing and refresh about http-core

[mcmanus]

I think Mark's suggestion is right. I would characterize HTTP/1.0 as ambiguous and that causes revalidation deadlocks. Its somewhat worse that this pattern needlessly shows up in HTTP/1.1 as well.

I think the text in 3.1 should change to:

A response message is considered complete when all of the octets indicated by its framing are available. A message that is not explicitly framed (e.g., when a HTTP/1.1 message does not use Content-Length or Transfer-Encoding for delimitation; see [Messaging], Section 6.3) SHOULD be considered incomplete.

[mnot]

Also, in the sentence:

A cache must not send a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.

...I think s/partial/incomplete/, based on context. Any concerns there?

[mnot]

In 4.3.1. Sending a Validation Request, add:

A cache MUST NOT send validation requests for stored responses that are incomplete; see (ref to 3.1. Storing Incomplete Responses).

[reschke]

3.1 currently has:

A response message is considered complete when all of the octets indicated by the message framing ([Messaging]) are received prior to the connection being closed.

Observations:

1. the reference really should be more specific and go to "6.3. Message Body Length"
2. is this clear enough for protocols other than HTTP/1.1?

[mnot]

Referring to h1-messaging 6.3 would make this specific to H1. Referring to 4.3.1 in caching keeps it protocol-generic. If another version doesn't crisply define what's an incomplete message, we can deal with that separately.

[mnot]

I think the text in 3.1 should change to:

A response message is considered complete when all of the octets indicated by its framing are available. A message that is not explicitly framed (e.g., when a HTTP/1.1 message does not use Content-Length or Transfer-Encoding for delimitation; see [Messaging], Section 6.3) SHOULD be considered incomplete.

[MikeBishop]

This seems reasonable. It's also related to quicwg/base-drafts#1972, asking whether servers can wait for end-of-stream to consider a message complete in HTTP/3. (Proposal in quicwg/base-drafts#2003 is "no, you can't.")

[royfielding]

No, HTTP/1.0 is consistently optimistic. If the server desires more rigor, it can do the work to supply the framing that would indicate an error occurred. When it fails to do so, it is deliberately choosing to maximize performance over correctness. Hence, the assumption has always been that a close-delimited message is always complete.

[mnot]

Thinking on this for a while, I think MAY might be more appropriate than SHOULD here; I have a strong suspicion that most caches will not consider a close-delimited response as incomplete.

I could test it, I suppose.