- From: Yaron Goland <yarong@microsoft.com>
- Date: Mon, 4 Nov 1996 14:40:55 -0800
- To: "'Roy T. Fielding'" <fielding@liege.ICS.UCI.EDU>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
Sending those headers involves overhead, a lot of overhead on slower links. We should have a means of indicating if we want a particular response stream. I know, I know, its not a proper use of a header. I agree and am open to suggestions. Where is the balance to be struck? Yaron >-----Original Message----- >From: Roy T. Fielding [SMTP:fielding@liege.ICS.UCI.EDU] >Sent: Monday, November 04, 1996 11:25 AM >To: w3c-dist-auth@w3.org >Subject: Re: Opinion on Notify Request Header > >Larry wrote: >> Oh, so it's a versioning issue, not a client capability issue. That >> makes sense. Status might be signalled by a >> >> 102 Processing >> >> status code, probably with an entity body which contains the actual >> status. This would signal the client that the server is still working >> on the request and not to time out. > >Yes, that's one of the reasons why 1xx codes were re-introduced. > >> We could add a new request header which indicates a client's >> willingness to accept such a status code, or else just bundle it in >> with HTTP/1.2 >> GET uri HTTP/1.2 >> >> would be the signal that '102 processing' responses are acceptable. > >Unnecessary. Any HTTP/1.1 client must treat all unrecognized 1xx responses >as if they were 100 responses. Any client that doesn't is not using >HTTP/1.1. >The only thing you have to remind people of is that they can't send or >forward any 1xx response to an HTTP/1.0 client. > >.....Roy (and any implementer that screws-up on that part of the protocol > is going to get a severe thrashing from me, since it is the key > to status extensibility) >
Received on Monday, 4 November 1996 17:52:34 UTC