[racket] Web server "Server" header

I just made a push. Here's the doc changes that describes the change:

An HTTP response where output produces the body. code is the response
code, message the message, seconds the generation time, mime the MIME
type of the file, and headers are the headers. If headers does not
include Date, Last-Modified, Server, or Content-Type headers, then the
server will automatically add them. The server will always replace
your Connection header if it needs to ensure the connection will be
closed. (Typically with an HTTP/1.0 client.)

I think this will satisfy all.

Jay

2011/4/12 Norman Gray <norman at astro.gla.ac.uk>:
>
> 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
>
>



-- 
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93