W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: [google-gears-eng] Re: Deploying new expectation-extensions

From: Charles Fry <fry@google.com>
Date: Sat, 5 Apr 2008 10:37:31 -0400
Message-ID: <b549193f0804050737u66855cafy1bb783019ea3b2ed@mail.gmail.com>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Brian McBarron" <bpm@google.com>, google-gears-eng@googlegroups.com, "Mark Nottingham" <mnot@yahoo-inc.com>, "HTTP Working Group" <ietf-http-wg@w3.org>

> > >  Can't the origin server just send the 103s without being asked for it?
> That
> > > would allow the client to discover support for the feature.
> > >
> >
> > Hmm. Now this is starting to come full-circle. As I understand it the
> > whole reason that Expect: 100-continue is used in conjunction with 100
> > Continue responses is to ensure, as the request is finding its way to
> > the origin server, that the response will be able to find its way
> > back, being properly interpreted as an intermediate response. Without
> > this there is the risk that a non-100-continue-aware proxy would
> > interpret the 100 response as a final response.
> >
>  I think that is incorrect.
>  Expect is needed in this case, because the client will not start sending
> the request body until the 100 Continue response has been received.
>  So in this case, it's essential for the protocol to work at all.

If you are correct, then that implies (as I understand it) that Expect
is the wrong mechanism for 100 continues, as the only requirement is
an end-to-end request and interim response, with no hop-by-hop
requirements. I am just trying to fully understand why an Expect would
be necessary for some 1xx responses and not others.

Received on Saturday, 5 April 2008 14:38:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC