- From: Koen Holtman <koen@win.tue.nl>
- Date: Fri, 18 Jul 1997 22:09:28 +0200 (MET DST)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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 complexity. 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. >-Jeff Koen.
Received on Friday, 18 July 1997 13:29:00 UTC