Titus Brown wrote:
> -> > First problem is that quixote.server.medusa_http does not pass all HTTP
> -> >header. I need Authorization header to implement Basic Auth authorization
> -> >scheme. Attached is a patch... just a few lines copied from
> -> >twisted_http.py.
> ->
> -> +1 for the patch, especially the header-propogation part. I had meant to do
> -> this myself, thanks Oleg for taking the time. (That snippet from
> -> twisted_http was itself borrowed from twisted.web.twcgi, by the way.)
> ->
> -> I'd encourage the other 'server script' maintainers to use a similar
> -> tactic; Quixote apps should always have access to the whole request, IMO,
> -> not just selected headers; and this should be the case regardless of what
> -> Web server is being used.
>
> Err... do you mean "Quixote apps should always have access to the whole
> request, formatted by the de facto rules that Apache uses for CGI"?
>
> To my knowledge, there's no other standard for what headers should be
> created, so I'm curious to find out if there are any ;).
I'd reword that to "...formatted according to the CGI/1.1 spec." There is such
a beast, still in Internet Draft (!), see http://www.w3.org/CGI/ . Bear in mind
that I am not a Apache/CGI consumer, so I'm not familiar with Apache's CGI
rules and how they may differ.
The HTTP_* catch-all technique is specified under section 6.1.5. There are a
number of MAYs in there, so admittedly it's a weak specification:
6.1.5. Protocol-Specific Metavariables
These metavariables are specific to the protocol via which the
request is made. Interpretation of these variables depends on
the value of the SERVER_PROTOCOL metavariable (see section
6.1.17).
Metavariables with names beginning with "HTTP_" contain values
from the request header, if the scheme used was HTTP. Each
HTTP header field name is converted to upper case, has all
occurrences of "-" replaced with "_", and has "HTTP_"
prepended to form the metavariable name. Similar
transformations are applied for other protocols. The header
data MAY be presented as sent by the client, or MAY be
rewritten in ways which do not change its semantics. If
multiple header fields with the same field-name are received
then the server MUST rewrite them as though they had been
received as a single header field having the same semantics
before being represented in a metavariable. Similarly, a
header field that is received on more than one line MUST be
merged into a single line. The server MUST, if necessary,
change the representation of the data (for example, the
character set) to be appropriate for a CGI metavariable.
Servers are not required to create metavariables for all the
request header fields that they receive. In particular, they
MAY decline to make available any header fields carrying
authentication information, such as "Authorization", or which
are available to the script via other metavariables, such as
"Content-Length" and "Content-Type".
Again, I don't know how that varies from Apache's behaviour.
I think, for the sake of completeness, that all HTTP headers should be passed
into the environment with the HTTP_ prefix. This would mean that some headers,
such as Content-Length, would exist in the environment both as CONTENT_LENGTH
and HTTP_CONTENT_LENGTH, but the redundancy is acceptable IMO. My rationale is
that if I want to reconstruct the original HTTP header, ignoring whatever
variables may have been introduced by Quixote or any other intermediary, I
could reliably use `[(k,v) for k,v in req.environ.items() if
k.startswith('HTTP_')]`. This could prove useful in debugging, and also ends
the add-variables-as-we-need-'em phenomenon that has already occured in
medusa_http and, I believe, scgi.
So, I'd offer the following revision: "In addition to the standard CGI
variables, Quixote apps must have access to all of the original request headers
via HTTP_ prefixed environment variables, as allowed for in the CGI/1.1
specification."
>
> cheers,
> --titus
All the best,
-- Graham