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

Re: [W3C BPWG] HTTP header fields X-* and normal ones / question

From: <eduardo.casais@areppim.com>
Date: Wed, 21 Jan 2009 22:44:57 +0000
To: <ietf-http-wg@w3.org>
Message-ID: <000001c97c19$cb514f60$ec9dca3e@AREPPIM002>




I realize that my original message would have actually
required some more context. I hope the following 
additions will make things clear.

> That's even more insane.  If the request is being 
> rewritten then it is not the same request -- the old 
> request fields should not be sent at all.
> The inbound server doesn't care about these values 
> and sure as hell doesn't want to parse them as part 
> of the request. As such, your deployed proxies are
> irrelevant.

Application servers in the mobile Web are highly dependent
on the Accept-* and User-Agent fields to generate content
that matches the capabilities of the terminal issuing the
request. In particular, the User-Agent serves as identifier
to retrieve information about, for instance, screen dimensions,
acceptable page size, browser quirks, from terminal capability
databases.

Content transformation proxies that intend to convert desktop
Web content to mobile Web content alter these capability
fields to appear as a normal desktop browser (e.g. IE, Firefox), 
but send the backup fields (X-Device-*) along for two reasons:

1. It is impossible a priori to determine reliably whether 
the target server returns desktop content or mobile content;
and
2. servers of mobile Web applications require the original
capabilities to adjust the content for the end terminal.

If a mobile Web server receives the modified request without
the backup fields, it will either fail to return a proper
result (because the terminal appears to be a desktop), or
produce a generic desktop-oriented page instead of a much
more adequate mobile-optimized one.

The question whether the transformation proxies should or 
should not modify the HTTP header fields in the first place
is another question; we are considering the scenario where
they do here.

>> 3) Questions to the IETF.
>>
>> 3.a: What is the IETF procedure, policy, standard, or 
>> best practice regarding the promotion of X- header 
>> fields to normal, registered (provisionally or
>> permanently) header fields?
>
> Never use them in deployed software. The X-prefix is 
> for private use in experiments that are NOT EXPOSED TO 
> THE INTERNET.

This just does not correspond to what is happening on 
the Internet.

Several browsers, notably Microsoft IEMobile, OperaMini, 
and Skyfire do send several X- prefixed HTTP fields that 
are not private, are fully exposed, documented, and that 
are supposed to be used by application servers.

As another example, the Open Mobile Alliance has a published
standard, UAProf, which relies on X-* prefixed HTTP header 
fields (X-Wap-Profile-Warning, X-Wap-Profile-Diff, and 
X-Wap-Profile). These HTTP header fields serve to communicate
terminal descriptions between end-user devices and servers.

The UAProf standard is widely deployed and heavily used on the
Internet, and can be found in the following references:
current version: 
OMA User Agent Profile, OMA-UAProf-v2_0-20030520-C, 2003-05-20.
initial version:
WAG UAProf, WAP-248-UAPROF-20011020-a, 2001-10-20.

I do not know why the OMA did not register proper HTTP 
fields in the IANA registry, but this has been the state
of affairs since 2001.

>> 3.c: What is the procedure, policy, standard or best 
>> practice of the IETF regarding the deprecation and 
>> discontinuance of HTTP header fields?
>
> Just stop using them.

But what if they have been registered? Would that not amount
to leaving chaff behind and cluttering the registry with
obsolete definitions?


Regards

Eduardo Casais
areppim AG
Bern, Switzerland
Received on Thursday, 22 January 2009 09:50:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:00 GMT