[racket] Web server "Server" header

Jay, hello.

On 2011 Apr 12, at 15:28, Jay McCarthy wrote:

> Is it an error to not include this header? I'm not interested in the
> subtle advertising to log readers, so it doesn't really matter to me
> what is says.

I don't think that any headers are required.  I can't find an explicit statement of this in the RFC, but I can see nothing about headers being required.

> What's the behavior when there are two Server headers? Because you can
> just as easily pass another one in the optional header list.

If you add a further Server header to the response structure, then you get two Server headers in the result sent back over the wire.

Sect. 4.2 of the RFC says:

Multiple message-header fields with the same field-name MAY be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list [i.e., #(values)].
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.

However neither Server nor Last-Modified (which I'd also potentially like to set) is of this type, so this appears to make it illegitimate to have multiple Server or Last-Modified headers.  The Server header can have multiple 'product' values, but they're separated by spaces rather than commas (this also, incidentally, means that a value such as 

    Server: Racket my-server/0.1

would allow both bits of software to be mentioned); Last-Modified is definitely single-valued.

The point of the Server header isn't so much advertising to log readers, as indicating who should be blamed, or be sent bug reports, if a server is misbehaving.

> I don't like the idea of a parameter or another field in the response
> data structure, but maybe I should just add an optional argument to
> response/xexpr and then remove the automatic insertion in the code you
> quote.

I'm using this by filling in fields in the response structure, rather than just via response/xexpr (it's not just XML I'm returning), so I'd be in trouble if the only way of setting this was via the latter.

Would it be possible to adjust output-response-head so that it only output those defaulted fields if there wasn't a corresponding header in the response-headers field list?  The semantics would therefore be that the response-headers field values override the built-in defaults.

If it's relevant, I don't think the order of the response headers is significant.  The RFC doesn't say this explicitly, but I think only mention of header ordering is in the passage quoted above, which only discusses the same header being repeated.  In other words, if a hash got involved here, that wouldn't matter.

Best wishes,

Norman


-- 
Norman Gray  :  http://nxg.me.uk