W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1998

RE: MUST use Content-Base

From: Yaron Goland <yarong@microsoft.com>
Date: Sun, 11 Jan 1998 23:18:32 -0800
Message-Id: <3FF8121C9B6DD111812100805F31FC0D0E7282@red-msg-59.dns.microsoft.com>
To: 'Henrik Frystyk Nielsen' <frystyk@w3.org>, "'jg@pa.dec.com'" <jg@pa.dec.com>
Cc: Foteos Macrides <MACRIDES@sci.wfbr.edu>, koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5139
I can live with the SHOULD followed by a note.

	Yaron (Declare Victory and Go Home)

> -----Original Message-----
> From:	Henrik Frystyk Nielsen [SMTP:frystyk@w3.org]
> Sent:	Sunday, January 11, 1998 10:27 PM
> To:	Yaron Goland; 'jg@pa.dec.com'
> Cc:	Foteos Macrides; koen@win.tue.nl;
> http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Subject:	RE: MUST use Content-Base
> At 17:35 01/10/98 -0800, Yaron Goland wrote:
> >A server recieves a GET from a client, the request is marked HTTP/1.1.
> The
> >server now knows it is dealing with a 1.1 client. So, no problem,
> according
> >to the HTTP/1.1 Draft Standard a 1.1 client MUST honor the content-base
> >header. So the server sends down a content-base expecting that the body
> will
> >be interpreted using the content-base header to resolve relative URIs. Of
> >course now the wrong thing will happen, the IE client will NOT honor the
> >content-base header because it is based on the proposed standard where
> >content-base is a MAY and the whole situation falls apart.
> Yes, this is no surprise and is yet another example showing that version
> numbers don't work on features. Content-base is always at risk of not
> working, even if all HTTP/1.1 applications understood it:
> 	A HTTP/1.1 caching proxy sends a request to an HTTP/1.1
> 	server, gets back an entity with a content-base and
> 	puts it into the cache. Now an HTTP/1.0 client comes
> 	along and gets the entity from the cache, ignores the
> 	content-base and the links will break.
> You can substitute content-base with content-encoding, content-type,
> content-language, and pretty much any other characteristic of the
> resource.
> The real problem is that sometimes this is OK and sometimes it's not - it
> depends on the type of client asking. In the case of content-base, I don't
> care if my client doesn't parse the darn thing.
> We went through a lot of hickups solving this for content-encoding but I
> doubt that anybody is willing to do the same for content-base. To me, this
> leaves two  ways of dealing with the problem:
>   1) leave it as is admitting that this was an evolutionary mistake
>   2) try an patch it and mention that "your milage will vary"
> I think I read from the discussion that people see a (limited) need for
> the
> feature, so maybe the right thing is to use a SHOULD and then include a
> note like this:
> 	Note: Many applications based on RFC 2068 or
> 	previous versions of HTTP ignore the content-base
> 	header field when parsing relative URIs in
> 	documents.
> Henrik
> --
> Henrik Frystyk Nielsen,
> World Wide Web Consortium
> http://www.w3.org/People/Frystyk
Received on Sunday, 11 January 1998 23:20:33 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC