User-Agent in HTTP requests
Thomas Boch
boch at newb6.u-strasbg.fr
Tue Mar 24 07:45:58 PDT 2009
Hi Mark,
Your suggestion sounds OK to me. I understand the need for data
providers to track the usage of their services. Moreover, adding a
sensible value for the user agent seems very straightforward (at least
in Java applications).
I therefore plan to implement this in the upcoming version of Aladin.
Cheers,
Thomas
Mark Taylor wrote:
> Dear Apps'n'DAL,
>
> I recently had a conversation with Alberto Micol about VO service
> providers (e.g. the administrators of SSA servers) wanting to find
> out more about who is consuming their services, in particular
> which software tools are originating requests. This information
> may be useful to service providers for gathering statistics,
> investigating usage patterns, tracking down illegal/problematic
> service usages, or for other reasons. It may be of interest to
> application authors too if the information is made available to them.
>
> We considered the possibility of adding an optional client application
> name parameter to the relevant protocols, so for instance a cone search
> request to the service http://cone.org/ngc from the client TOPCAT
> might use the URL:
>
> http://cone.org/ngc?RA=56.20&DEC=24.29&SR=0.01&CLIENT=topcat
>
> However, this would mean changes to all the DAL service standards
> (and others?) and clutter up those standards with options which are
> really orthogonal to their purpose.
>
> I think that a better solution is to use the existing mechanism of
> the HTTP "User-Agent" request header; see RFC2616 sec 14.43:
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43
>
> This is a sensible place to put information about the source of the
> request, and since it is an existing part of HTTP it won't break
> anything or require any changes to standards. Some applications
> may already be populating this field appropriately in any case.
>
> This may not be possible for portal-type systems which work by
> embedding service access URLs in HTML, though in those cases
> the HTTP "Referer" header (RFC2616 sec 14.36) may provide the
> relevant information.
>
> How easy or difficult it is for clients to populate the User-Agent
> field appropriately will vary according to language used; in Java
> the easiest way is for the client author to set the System Property
> "http.agent" to a suitable string near application startup time
> (http://java.sun.com/javase/6/docs/technotes/guides/net/properties.html).
> Experts in other languages may be able to provide similar tips
> for those.
>
> Since populating the User-Agent header in this way may be useful to
> some service providers and should at worst be harmless, I plan to
> implement it forthwith in my applications.
>
> The purpose of this message is:
>
> 1. to encourage other application authors to do the same, for the
> benefit of service providers who may wish to make use of this kind
> of information (if you plan to do so, a "me too" follow-up to this
> message would be useful to gauge response)
>
> 2. to advertise the fact to service providers that the User-Agent
> field is a good place to look for client-type information
> (or at least may become so after some application authors have
> followed up this idea)
>
> 3. to enquire whether service providers agree that this is a good
> way to provide this information, or whether this information is
> of no interest, or whether there are other similar things that
> application authors can do to help along these lines.
>
> If this is generally accepted as a good idea, perhaps it should be
> formalised somewhere as good practice for application authors
> who may be consuming VO services. However I'm not sure what would
> be be the best way to go about this - it's a very small suggestion,
> so an IVOA Note would seem like overkill. An IVOA Note "Guidelines for
> authors of VO applications" might be a nice idea - but I'm not sure
> what else would go in it :-).
>
> Mark
>
>
More information about the apps
mailing list