Opened 6 years ago

Closed 6 years ago

#458 closed design (fixed)

Requirements upon proxies for Expect

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 "Requirements for HTP/1.1 proxies" bullet one effectively requires proxies to forward ALL requests with Expect: 100-continue if the inbound server is HTTP/1.1 -- even if the request is a GET.

I know that this isn't the intent, but that's how it reads; suggest qualifying this to only apply to requests with bodies.

The next bullet requires proxies to respond with a 417 if the inbound server is HTTP/1.0. Just curious here - why? Wouldn't the maximally interoperable thing be to generate a 100-continue yourself? While the client *could* resubmit the request, they probably won't, because as far as they know, the origin told them not to.

Change History (13)

comment:1 Changed 6 years ago by fielding@…

p2 5.1.1 "Requirements for HTP/1.1 proxies" bullet one effectively requires proxies to forward ALL requests with Expect: 100-continue if the inbound server is HTTP/1.1 -- even if the request is a GET.

I know that this isn't the intent, but that's how it reads; suggest qualifying this to only apply to requests with bodies.

See the general requirement in 5.1.1 for forwarding Expect. This was part of the design of Expect, such that the expectations had to be satisfied end-to-end. Perhaps we could add "unless required otherwise by the requirements on a recognized expectation"?

The next bullet requires proxies to respond with a 417 if the inbound server is HTTP/1.0. Just curious here - why? Wouldn't the maximally interoperable thing be to generate a 100-continue yourself? While the client *could* resubmit the request, they probably won't, because as far as they know, the origin told them not to.

http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997MayAug/0401.html

http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997MayAug/0485.html

I won't attempt to explain the intent behind a redesign by committee of a very simple feature into a nearly useless and incompatible set of requirements (incompatible with those of RFC2068).

However, what 417 says is that the expectation failed. Why wouldn't the client resubmit the request without Expect?

My inclination is to close this as WONTFIX, unless you want us to change the Expect semantics.

comment:2 Changed 6 years ago by mnot@…

Perhaps we could add "unless required otherwise by the requirements on a recognized expectation"?

I think we can do better than that; will take a look and make a separate proposal.

However, what 417 says is that the expectation failed. Why wouldn't the client resubmit the request without Expect?

Because the whole point of 417 is saying "I won't service this request, please don't send it" -- at least when it's generated by the origin server. When it's generated by an intermediary, it muddies those semantics. A client can't tell the difference.

My inclination is to close this as WONTFIX, unless you want us to change the Expect semantics.

It's not a change to semantics from the client's standpoint, in that they have to be prepared to receive responses other than 100 and 417 anyway, from earlier-than-1.1 implementations, as well as the many, many implementations that already do this.

I see this change as reflecting reality (it's already deployed widely), improving interop (because it's really bad) and clarifying the spec (incompatible and nearly useless). That's all squarely in-scope for us.

comment:3 Changed 6 years ago by fielding@…

417 says that the expectation isn't supported, nothing else. If the client can repeat the request without the expectation, it should do so. I agree that this is poorly specified.

Regarding the other issues, I just checked the main origin server implementations (Apache, nginx, IIS) and have concluded that we are better off making Expect reflect reality at this point than continue with an obviously broken feature.

Apache is the only server that sends 417 on unknown expectations in general. nginx patches implement Expect, but only for file uploads, only for 100-continue, and only if the request is succeeding. IIS does not appear to support Expect at all, though perhaps I've just been hitting the wrong resources. None of them support the extensibility syntax.

Do you have any idea about intermediary support for Expect?

I have already done some rewriting of the section, but it would be a lot easier to spec if we could decide to remove the extension mechanism first.

comment:4 Changed 6 years ago by mnot@…

I tried to get rid of it in #486; no one else wanted to. If you make an argumetn on the list, I'm happy to reopen it.

comment:5 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:6 Changed 6 years ago by fielding@…

I hope that [2350] is sufficient to address the first concern.

The second concern (the requirement to send 417 if next hop is HTTP/1.0) would be a more significant design change. I am happy to make that change (to require responding with 100 on behalf of the chain) if the WG agrees.

comment:7 Changed 6 years ago by fielding@…

From [2351]:

Add a client SHOULD repeat without the expectation requirement for clients that receive 417 due to Expect and 100-continue; addresses #458

comment:8 Changed 6 years ago by mnot@…

Roy, is this completely incorporated from your perspective?

comment:9 Changed 6 years ago by fielding@…

From [2380]:

Remove the Expect extension mechanism to focus on the definition of 100-continue; allow proxies to generate 100 on behalf of inbound HTTP/1.0 servers; addresses #458 and #468

comment:10 Changed 6 years ago by fielding@…

  • Milestone changed from unassigned to 24
  • Resolution set to incorporated
  • Status changed from new to closed

comment:11 Changed 6 years ago by julian.reschke@…

From [2386]:

Note changes for [2380] (see #458 and #468)

comment:12 Changed 6 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:13 Changed 6 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.