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: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 22 Jan 2009 16:29:19 -0800
Message-Id: <D8B1765E-639B-4C25-890A-6422FF4ADC3C@gbiv.com>
Cc: <ietf-http-wg@w3.org>
To: <eduardo.casais@areppim.com> <eduardo.casais@areppim.com>

On Jan 21, 2009, at 2:44 PM, <eduardo.casais@areppim.com>  
<eduardo.casais@areppim.com> wrote:
> 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.

Yeah, so don't change that information.

> 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.

A content transformation proxy does not want the "server of
mobile web applications" to return content that is adjusted
specifically for that terminal.  If they did, they wouldn't need
to change all of the request fields in the first place to
pretend not to be that terminal.  They would just forward the
original request without change, or adjust the parameters in
the modified request such that device-specific media types
are preferred over standard media types.

A content server DOES NOT want to know about some request
parameters other than what it is already designed to vary
the representation.  What you suggest would require those
servers to also Vary the content by these X-Device header
fields and specifically not comply with the standard fields
for content negotiation.  In short, you are asking that servers
fail to correctly handle the request as specified and make
caching far less effective at the same time, in addition to
doubling the latency on request parsing due to these useless
header fields being sent to servers that have no interest
in reading them.

In short, whatever problem you think you are trying to solve
will not be solved by the suggested solution, so asking further
about how this bad idea might be registered is pointless.

> 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.

The answer to that consideration is that the transformed
request must be considered on its own, as requested, and
the fact that it originated from a mobile device is irrelevant.
The origin server is only responsible for responding to the
request as it was requested by the proxy.  If the proxy is
making the wrong transformation, then fix the proxy.

>>> 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.

And they will never be standardized for that reason.  In fact,
I'll happily add code to strip them out of requests before
the application server has a chance to see them.

> 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 OMA is not a standards organization.  I don't recommend
following any of their specifications.

> 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.

Again, I will happily block them if that will solve the problem
of it being considered precedence for not reading the relevant
standards regarding registration.

>>> 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?

They aren't registered yet.  Even if they were, I'd rather have
a crufty bunch of useless fields in the registry than a crufty
bunch of useless fields on the wire on every request.

....Roy
Received on Friday, 23 January 2009 00:30:01 GMT

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