HTTP Accept header

[Zarquan]

The UWS specification has the following text:

HTTP allows multiple representations of a resource distinguished by their MIME types and selected by the HTTP "Accept" headers of a GET request. A UWS implementation can exploit this to support both web browsers and rich clients in the same tree of resources. Although the default behaviour is to return XML, a UWS could return HTML or XHTML to clients that accept these types. These clients are assumed to be web browsers and the UWS is generating its own user interface. The HTML interface generated should allow full control of the UWS via the use of HTML forms and appropriate links.

Should this be moved to DALI and made consistent across all DAL services ?

[pdowler]

It could... any service can support this already so would it add much to say so in DALI? The first thing that would happen is confusion between Accept header and the RESPONSEFORMAT parameter. The latter is usable to control the representation format of async job results, while Accept is only applicable to the current http request/response.

If we aren't careful, we just make it such that TAP-async has one way to control output form and TAP-sync has two ways; then we also have to decide which one "wins" of both are present and also spec compliance issues (I'm sure).

My personal 2c: we use Accept (at CADC) where it makes sense (mainly to support our own web UI) but I'd be cautious about mentioning it in a DALI; in a standard about a specific endpoint behaviour with a defined payload (eg UWS) it makes some sense to mention it, but even in the above quote it's clearly optional with no way to discover that a service does something with Accept headers and what mime types might actually work (othwer than the http way of sending accept header and seeing what comes back)