Opened 7 years ago

Closed 6 years ago

#466 closed editorial (incorporated)

Editorial for Expect/Continue

Reported by: mnot@… Owned by: draft-ietf-httpbis-p2-semantics@…
Priority: normal Milestone: 24
Component: p2-semantics Severity: In WG Last Call
Keywords: Cc:

Description

  • p2 5.1.1 says "A recipient of a syntactically invalid Expectation header field must respond with a 4xx status code other than 417." We should recommend something specific; e.g., append "(usually, 400 (Bad Request))".
  • p2 5.1.1.1 says "The 100-continue expectation does not use any expect-params." We should specify that they're to be ignored by recipients.
  • p2 5.1.1.1: "If an origin server receives a request that does not include an Expect header field with the "100-continue" expectation, the request includes a payload body, and the server responds with a final status code before reading the entire payload body from the transport connection, then the server should not close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise, the client might not reliably receive the response message. However, this requirement ought not be construed as preventing a server from defending itself against denial-of-service attacks, or from badly broken client implementations."

This seems out of place (it's about connection management) and largely redundant with the text in p1 6.6.

  • p2 6.2 says: "Since HTTP/1.0 did not define any 1xx status codes, servers must not send a 1xx response to an HTTP/1.0 client except under experimental conditions." Since this applies to proxies forwarding responses, it needs to be mentioned somewhere in p1 too.
  • p2 6.2 says: "Proxies must forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the 1xx response." There needs to be a get-out clause for when there's an HTTP/1.0 client; otherwise this requirement is in conflict with the one above.

Change History (4)

comment:1 Changed 6 years ago by fielding@…

p2 5.1.1.1: "If an origin server receives a request that does not include an Expect header field with the "100-continue" expectation, the request includes a payload body, and the server responds with a final status code before reading the entire payload body from the transport connection, then the server should not close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise, the client might not reliably receive the response message. However, this requirement ought not be construed as preventing a server from defending itself against denial-of-service attacks, or from badly broken client implementations."

This seems out of place (it's about connection management) and largely redundant with the text in p1 6.6.

Fixed in [2344].

comment:2 Changed 6 years ago by fielding@…

p2 5.1.1 says "A recipient of a syntactically invalid Expectation header field must respond with a 4xx status code other than 417."

We should recommend something specific; e.g., append "(usually, 400 (Bad Request))".

Hmm, I see a typo. Can we just delete that last sentence? I see no need to special-case the syntax handling of Expect. In fact, the first part of the paragraph belongs above it as part of the header field definition, so I will rewrite both.

The normal behavior for a server is to send an error response if the request would cause an error (i.e., 401) and only to process Expect: 100-continue if it might be worth sending 100. 400 is certainly a valid response to bad syntax, but that is obvious.

p2 5.1.1.1 says "The 100-continue expectation does not use any expect-params."

We should specify that they're to be ignored by recipients.

I suspect that sending them would cause an interop problem. Has anyone checked? It seems that this ABNF was changed since 2616 -- the extension syntax used to be limited to extensions.

p2 6.2 says: "Since HTTP/1.0 did not define any 1xx status codes, servers must not send a 1xx response to an HTTP/1.0 client except under experimental conditions."

Since this applies to proxies forwarding responses, it needs to be mentioned somewhere in p1 too.

I think we can remove "except under experimental conditions" (experiments don't need to comply anyway).

p2 6.2 says: "Proxies must forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the 1xx response."

There needs to be a get-out clause for when there's an HTTP/1.0 client; otherwise this requirement is in conflict with the one above.

Okay.

comment:3 Changed 6 years ago by fielding@…

From [2350]:

Rewrite the sections on Expect and 100-continue to simplify the requirements (remove redundant or impossible conditions) and fix contradictions; addresses #458 #466 #467

comment:4 Changed 6 years ago by fielding@…

  • Milestone changed from unassigned to 24
  • Resolution set to incorporated
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.