- From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
- Date: Wed, 07 Aug 1996 21:49:45 -0700
- To: Paul Leach <paulle@microsoft.com>
- Cc: 'http-wg' <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
> 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. Ummm, I guess this is one of those things that should have been said in the section on message field parsing.... An empty header field value has a meaning which is distinct from a nonexistant header field. An analogy is a variable in Perl -- no header field is equivalent to a value of undefined (a null pointer), whereas a header field with an empty or whitespace-only value is equivalent to an empty value (a pointer to a zero-length data segment). Whether or not those two have equivalent semantics is dependent on the definition of the header field, just as Accept: means accept nothing (if no other Accept headers are in the message) and no Accept header field means accept anything. > There must be some mechanism like this, independent of the semantics of > any request header, in order for sticky headers to work at all. Time to look for another mechanism... Connection: sticky Sticky: reset="Accept" and assorted other yucky ideas come to mind. BTW, while we are on the topic, I would prefer that the two unrelated concepts of sticky headers and short header names be in two separate drafts. They should be evaluated independently. ...Roy T. Fielding Department of Information & Computer Science (fielding@ics.uci.edu) University of California, Irvine, CA 92697-3425 fax:+1(714)824-4056 http://www.ics.uci.edu/~fielding/
Received on Wednesday, 7 August 1996 22:02:24 UTC