Datalink feedback IV

[Mark Taylor]

On Fri, 28 Mar 2014, Markus Demleitner wrote:

> Hi list,
> 
> this time, it's about "3.3 Successful Requests".
> 
> What I don't like there is the sentence "The service should set the
> following HTTP headers to the correct values where possible." -- this
> is a bit of an empty statement.  Clearly, *all* http headers should
> be set to their correct values, and some of them must be or bad
> things are bound to happen (e.g., content-length with connection:
> keep; in particular, if you do content-encoding -- compression, say
> --, the corresponding header must be set accordingly or things will
> inevitably break).  
> 
> Anyway, I don't think we should be saying anything here that is the
> realm of HTTP.  We might recommend some best practices, but that would
> be better placed in an non-normative appendix.

+1 to this general principle.

> Considering this, I propose to only keep the first paragraph of 3.3
> and then add
> 
>   The content-type header of the response MUST be set to
>   application/x-votable+xml;content=datalink unless the incoming
>   request had a DALI RESPONSEFORMAT parameter, in which case
>   content-type follows DALI's rules.

Minor quibble: that would outlaw response content-types of for instance

    application/x-votable+xml;serialization=BINARY;content=datalink
    application/x-votable+xml;content=datalink;charset=iso-8859-1

or even

    application/x-votable+xml; content=datalink
    application/x-votable+xml;content="datalink"

This would probably not cause problems in practice, but it would be
more robust to say something like:

    ... MUST give a type/subtype of "application/x-votable+xml" with
    the "content" parameter set to "datalink"
    (e.g. "application/x-votable+xml;content=datalink") ...

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/