Not sure what WAP's strategy for this is but, off the top of my head, given
how User-Agent's are currently used (and abuse), one approach may be to
redefine User-Agent to limit it to a single product token and version, and
define a new Capabilities header whose value is a list of meaningful tokens
that identify stuff the user-agent is able to support.
User-Agent: Foo/1.0
Capabilities: u, mobile, something-else
Using the revised header structure I've suggested, it would be something
like...
[0, 9, 1, 0, 7, 'F', 'o', 'o', '/', '1', '.', '0']
[16, 2, 1, 23, 'u', 0, 'm', 'o', 'b', 'i', 'l', 'e',
0, 's', 'o', 'm', 'e', 't', 'h', 'i', 'n', 'g', '-',
'e', 'l', 's', 'e']
This definitely won't stop folks from lying about their user agents, but by
providing a clear location for "capabilities", perhaps we can stem many of
the ugly hacks that user-agent strings are currently used for.
- James
On Tue, Jul 17, 2012 at 12:49 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:
> In message <39a908269aed0fec3d0456ce7f7f38b2.squirrel@arekh.dyndns.org>,
> "Nicol
> as Mailhot" writes:
>
> >so a client signature to home on is nice.
>
> Agreed, we can't do without some form of User-Agent, if nothing else
> then for debug purposes, but if we could make it less of landfill
> and more meaningfull that would be A Good Thing.
>
> Anybody know what WAP did for this ?
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>
Received on Tuesday, 17 July 2012 20:06:15 UTC