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
On 9/5/12 12:33 PM, Robin Berjon ro...@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
On Wed, Sep 5, 2012 at 11:33 AM, Robin Berjon ro...@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
On Wed, Sep 5, 2012 at 12:03 PM, Mark Nottingham m...@mnot.net wrote:
The current draft of XHR2 doesn't allow clients to set the UA header.
Presumably, by clients you mean client-side script, and not the [client]
implementation of the UA.
That's unfortunate, because part of the intent of
The current draft of XHR2 doesn't allow clients to set the UA header.
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
+1
roBman
On Wed, 5 Sep 2012 14:03:35 +1000
Mark Nottingham m...@mnot.net wrote:
The current draft of XHR2 doesn't allow clients to set the UA header.
That's unfortunate, because part of the intent of the UA header is to
identify the software making the request, for debugging / tracing
