On Mon, Aug 1, 2016 at 2:13 PM, Jacob Champion <champio...@gmail.com> wrote:
> All right, getting back to this after a week off. I've tried to combine > feedback as best I can into one message. > > Bill, you wrote: > > I'm perfectly happy to translate such values to GMT for non-HTTP >> inputs, per spec. If we are going to do so for HTTP inputs, loudly >> scolding the errant developer in the logs seems prudent, for their own >> longer-term benefit. >> > > I suspect this is the core of the argument now. In my opinion, CGI is not > an HTTP input -- either as far as the spec is concerned (for spec lawyering > purposes) or in practice. > >From CGI RFC 3875 sect 1.1; "The Common Gateway Interface (CGI) [22] allows an HTTP [1], [4] server and a CGI script to share responsibility for responding to client requests" It has no other basis of existence, although it could of course be applied to other existing or future protocols. Section 1.4 calls out specific spec terms which differ from their HTTP equivalents. To your argument, section 3.1 has this to say... "The server MUST perform translations and protocol conversions on the client request data required by this specification. Furthermore, the server retains its responsibility to the client to conform to the relevant network protocol even if the CGI script fails to conform to this specification." Conforming can either refer to eliding a header line that doesn't conform, or munging a header line to a usable value, we could interpret that either way. I'll review the rest of your comments shortly, but you might want to review https://tools.ietf.org/html/rfc3875 before claiming CGI isn't an HTTP input :-) Cheers, Bill
