Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content framing and refresh #25

Closed
mnot opened this issue May 3, 2017 · 9 comments · Fixed by #221

Comments

@mnot
Copy link
Member

commented May 3, 2017

It'd be good to say something about how weakly-framed content (e.g., no Content-Length in 1.0; no CL or chunked in 1.1) should be handled differently by caches, especially during reload.

From httpwg/http-extensions#325

@mnot mnot added the h1-messaging label Jun 20, 2017
@mnot mnot added the caching label Oct 10, 2018
@mnot mnot self-assigned this Oct 10, 2018
@mnot

This comment has been minimized.

Copy link
Member Author

commented Oct 10, 2018

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).

@mnot mnot added the has-proposal label Oct 10, 2018
@mnot mnot removed their assignment Oct 10, 2018
@reschke

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Oct 11, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Nov 13, 2018

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 comment has been minimized.

Copy link
Contributor

commented Nov 14, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 14, 2018

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.

@mcmanus

This comment has been minimized.

Copy link

commented Nov 14, 2018

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 mnot self-assigned this Feb 26, 2019
@mnot

This comment has been minimized.

Copy link
Member Author

commented Apr 12, 2019

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.

@mnot

This comment has been minimized.

Copy link
Member Author

commented Jul 5, 2019

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.