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

RE: Sticky headers and pipelining (was: Sticky header draft --as an attachment)

From: Paul Leach <paulle@microsoft.com>
Date: Wed, 7 Aug 1996 15:25:25 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960807222525Z-8457@tide21.microsoft.com>
To: 'Jeffrey Mogul' <mogul@pa.dec.com>, 'Daniel DuBois' <dan@spyglass.com>
Cc: 'http-wg' <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>


>----------
>From: 	Daniel DuBois[SMTP:dan@spyglass.com]
>Sent: 	Wednesday, August 07, 1996 3:11 PM
>To: 	Paul Leach; 'Jeffrey Mogul'
>Cc: 	'http-wg'
>Subject: 	RE: Sticky headers and pipelining (was: Sticky header draft --as an
>attachment) 
>
>At 02:35 PM 8/7/96 -0700, Paul Leach wrote:
>>The mechanism for that in the draft is that the client sends the header
>>name and an empty value, which means that, even though there was a value
>>for that header in the last message, this message should be interpreted
>>as if the header with that field-name is not present in the message.
>>
>>There must be some mechanism like this, independent of the semantics of
>>any request header, in order for sticky headers to work at all.
>>[...]
>>One could invent a header with the property that (say)
>>	Foo:<CRLF>
>>meant one thing, and
>>	Foo: Yes
>>meant another. I don't believe that are currently any examples of this,
>>however. Certainly, either we would either have to outlaw adding any
>>such headers to HTTP, or outlaw their participation in the sticky header
>>mechanism.
>
>Uh.. The semantics of an empty Accept-Encoding are mentioned in the 11-06
>draft.  And I think the semantics of "Accept:<CRLF>" are both self-evident,
>and clearly not the same as a lack of the header.  Certainly the BNF allows
>numerous headers to be NULL.

Oh, foo. Drat. Darn. Shucks. I'll have to look at them. Mumble.
>
>I was presuming (not having read the draft, can I admit that in a discussion
>on the draft?) that your intentions were that a sticking client would
>indicate turning off individual headers on subsequent requests by sending
>the explicit format that was semantically equivalent to the default of those
>individual headers.

One can always do this. But is there a default for all headers? And is
it concise enough to be acceptable?

>  As in, sending "Accept-Encoding:<CRLF>" since empty and
>non-existant have the same meaning, or "Accept: */*" since that has the same
>meaning as non-existant.  This would mean that all stick-able headers must
>have a explict default-equivalent format (User-Agent:<CRLF> ??), or a that
>you need a global way to wipe off all the stickyness (Here's where I propose
>the Towel: header.), or, finally, that you have a
>"Stuck-Headers-That-Slipped-Off:" header.

I was trying to avoid either of the last two approaches. But maybe I
can't.

Paul
Received on Wednesday, 7 August 1996 15:31:11 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:06 EDT