httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c
Date Mon, 01 Aug 2016 20:17:48 GMT
On Mon, Aug 1, 2016 at 3:03 PM, Jacob Champion <> wrote:

> On 08/01/2016 12:38 PM, William A Rowe Jr wrote:
>> I'll review the rest of your comments shortly, but you might want to
>> review
>> before claiming CGI isn't an HTTP
>> input :-)
> I suspect we're talking past each other at this point. I'm aware of 3875
> (though I don't claim to be an expert), and I quoted it in my response. I
> am using the term "HTTP input" in response to your much earlier statement
> that
> (We aren't talking about non-HTTP sources.)
> We *are* talking about non-HTTP sources. CGI is *not* HTTP. It obviously
> shares a great deal of syntax, but a CGI application is neither an HTTP
> client nor an HTTP server, and it does not speak HTTP to our server.
> Therefore CGI is not an "HTTP input" and we are not bound by 723x's
> requirements for parsing date-stamps that originate from it -- which, IIUC,
> was your argument. The wisdom of doing so (or not) is a completely separate
> issue, outside the bounds of the spec.

We are bound by RFC 3875, which says...

 6.3.4.  Protocol-Specific Header Fields

   The script MAY return any other header fields that relate to the
   response message defined by the specification for the SERVER_PROTOCOL
   (HTTP/1.0 [1] or HTTP/1.1 [4]).  The server MUST translate the header
   data from the CGI header syntax to the HTTP header syntax if these
   differ.  For example, the character sequence for newline (such as
   UNIX's US-ASCII LF) used by CGI scripts may not be the same as that
   used by HTTP (US-ASCII CR followed by LF).

E.g. no accommodation of non-HTTP input as header fields, other than
to avoid hop-by-hop server <> client header fields, which httpd is required
to dodge.

View raw message