- From: Cameron Jones <cmhjones@gmail.com>
- Date: Thu, 6 Sep 2012 15:04:37 +0100
- To: Robin Berjon <robin@w3.org>
- Cc: Mark Nottingham <mnot@mnot.net>, public-webapps@w3.org
On Wed, Sep 5, 2012 at 11:33 AM, Robin Berjon <robin@w3.org> wrote: > On 05/09/2012 06:03 , Mark Nottingham wrote: >> >> That's unfortunate, because part of the intent of the UA header is to >> identify the software making the request, for debugging / tracing purposes. >> >> Given that lots of libraries generate XHR requests, it would be natural >> for them to identify themselves in UA, by appending a token to the browser's >> UA (the header is a list of product tokens). As it is, they have to use a >> separate header. > > > Do you have a use case that does not involve the vanity of the library's > authors? :) > I'm not sure how this constitutes vanity, do you mean because it would piggyback the app name into a prominent header? The same reasoning could be regarded against having a protected UA header as a means of enforcing usage stats. Is there supposed to be a security or privacy threat here? If an app overrides the UA header that would seem to be their own prerogative based on the request they deem to initiate. The use case for overriding the UA header is that, in a world of browser sniffing services, if a service does change their output based on UA header the only way to ever access such content is by replicating the exact environment, potentially in hardware and software. This functionality is useful in providing administrative access for online development, debugging and testing. Thanks, Cameron Jones
Received on Thursday, 6 September 2012 14:05:13 UTC