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

Re: Comment on PEP draft

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Thu, 08 May 1997 11:40:18 -0400
Message-Id: <>
To: Koen Holtman <koen@win.tue.nl>, http-wg@cuckoo.hpl.hp.com
Cc: Koen Holtman <koen@win.tue.nl>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3232
At 08:33 PM 5/5/97 +0200, Koen Holtman wrote:

Hi Koen,

Thanks for your comments and sorry for the delay...

>I have not had time to fully understand the new PEP draft yet, but I
>am very worried about the dynamic header name allocation scheme in
>there.  I have two questions:
>1) If I understand things correctly, servers could send a header like
>blah-1:, which was mapped by a user agent, in a response.  What
>happens if the server makes this response cachable?  Won't you have
>huge trouble if a user agent maps a new header to extension X and then
>gets the same header back in a response which was cached in a proxy 3
>days ago, when the header was mapped to extension Y by some other
>agent?  Or is there a way to prevent/detect such collisions?

Binding requests are always non-cacheable so the scenario you describe can
only happen on optional requests. 

A problem with long lived mappings is that the server has to know where a
mapping comes from, ie., what client issued the mapping. This is a problem
as HTTP doesn't provide a good mechanism for doing this. The transport
connection can not be used as this does not work on end-to-end extensions.
Instead, the best way is to provide a unique extension ID when declaring
the mapping, for example:

	GET /my.resource HTTP/1.1
	Host: some.host
	PEP: {{map http://www.w3.org/my.ext my-ext-*} {params {id abc}}

and then on following requests do something like

	GET /my.new.resource HTTP/1.1
	Host: some.host
	my-ext-id: abc

This construct is very easy to put into the vary field as all the server
needs to do is to include a header like this in the response

	200 OK
	Vary: me-ext-id

This is different from the previous model where all optional PEP extensions
also were non-cacheable and hence I see this as being an improvement.
Because the new PEP mapping follows the RFC822 model, it makes it a lot
easier to express the caching semantics in HTTP/1.1 messages.

The idea behind the mapping scheme is that PEP does not care about the
lifetime of a mapping - once you have declared it, according to PEP, you
can use it as you like. The trick is that if either of the parties forgets
about the mapping then this can be detected by the other end and an error
message generated.

Normally, proxies are not involved in any end-to-end extensions and hence
do not have to perform any PEP action what so ever. Only if they are taking
active party in making extensions, they have to make sure that they don't
remap already mapped headers. This is quite simple to detect as the origin
server can see the mapping declarations and can issue an error.

>2) I suspect that supporting header mapping will not be simple.  So
>what is the payoff of having the complexity of header mapping at all,
>in stead of just putting all information in the PEP header itself
>(which is where the previous draft seemed to be going)?  
>If the answer is just `saving bytes', I don't think the added
>complexity is warranted.  Saving header bytes by adding state, if done
>at all, should be done by a generalised mechanism in HTTP/1.2.

I am interested in hearing why you think why it is not simple! The design
is quite simple, really, and the implementation we are working on indicates
that this is a minor task as well. As we discussed in Memphis and Santa
Clara, there are several problems putting all information in a single header:

- It does not work well with existing HTTP/1.1 caches. New PEP works with
no problems at all (connection, cache-control, vary etc.)

- You can not have multiple instances of the same extension as they can not
be distinguished. In the new PEP, you just declare another set of mapped

- The verbosity of the protocol _is_ an issue. The new PEP allows
applications to do a mapping once and then for ever after use that mapping
without redeclaring it at all.

It is correct that the old model gets around the header clash problem
completely, but what the new model takes advantage of, is that the header
clash problem is easy to solve. Headers do only have to be unique between
the parties who are directly involved in a mapping.


Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
Received on Thursday, 8 May 1997 08:44:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC