httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c
Date Mon, 01 Aug 2016 19:38:23 GMT
On Mon, Aug 1, 2016 at 2:13 PM, Jacob Champion <champion.p@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

Mime
View raw message