W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: STATUS100 Re: Proposed resolution

From: Koen Holtman <koen@win.tue.nl>
Date: Fri, 18 Jul 1997 22:09:28 +0200 (MET DST)
Message-Id: <199707182009.WAA11447@wsooti08.win.tue.nl>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3809
Jeffrey Mogul:
>On the general topic of "is the whole status 100 thing worth having?":
>I've always been neutral on the topic.  However, several members
>of the HTTP/1.1 editorial group are firmly in favor of keeping
>it, as are at least some other members of the full working group.
>As far as I can tell, the consensus of the editorial group is
>"keep it, but fix it."

Reading your proposal, I think that overall you have done a good job
at fixing the language and at cutting away some of the unnecessary

It it now simple enough as far as I am concerned, though I would not
mind making it still more simple.

As far as I can see, a user agent which sends an Expect 100 would have
to have time-out code so that it can handle the case that the request
is done on an unknown server which turns out to be a 1.0 server, so
that there never is a 100 response or an error response, because the
server keeps waiting for a request body.  As this time-out code has to
be present anyway, I think we can get away with dropping the
requirement that proxies remember the versions of upstream servers,
and return error responses to an expect 100 if they know that the
upstream server is a 1.0 server.  We could simply add a note that an
expect 100 can only be used successfully over a pure 1.1 (or higher)
chain, and that agents can inspect the Via header field and status
line of an earlier request to the same server to see if sending an
expect 100 could be useful.  The note should also say that the
possibility of having a mesh of proxies including a 1.0 proxy, and of
servers simply switching to a lower protocol version if they like to,
means that a prediction based on Via cannot be 100% reliable.

As for my ASK-IF-ALLOWED proposal: I did not use OPTIONS because I did
not remember that it could be used for this at the time, but I see no
reason why this could not be done with OPTIONS.

Jeff writes:
>I don't believe that it's feasible to add a new method at this point,
>especially since it would not interoperate with existing proxies
>and servers.

Why would it not interoperate?  Proxies would simply relay it, like
they do with other unknown methods, and origin servers which do not
know the method would simply return an error.  Nothing breaks as far
as I can see, and no extra complexity is needed.  It would even work
over a 1.0 chain.


Received on Friday, 18 July 1997 13:29:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC