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

RE: MUST use Content-Base

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Mon, 12 Jan 1998 01:26:30 -0500
Message-Id: <3.0.3.32.19980112012630.006e2230@localhost>
To: Yaron Goland <yarong@microsoft.com>, "'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
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:08:29 EST

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