Robert Brewer wrote:
Brian Smith wrote:
Here is the change that removes the use of RFC 2047 from HTTP in
HTTPbis.
Yes, but parsers need to continue decoding them for many years to come.
IMO WSGI origin servers should do this so we can write the decoding
logic once and forget about
Alan Kennedy wrote:
[Brian]
Here is the change that removes the use of RFC 2047 from HTTP in
HTTPbis.
Grand so; all we need to do is to wait for everyone to stop using
HTTP/1.1, start using HTTP/bis, and our problems are at an end!
HTTPbis *is* (will be) HTTP/1.1. It doesn't define a new
Here is the change that removes the use of RFC 2047 from HTTP in HTTPbis.
-Original Message-
From: ietf-http-wg-requ...@w3.org [mailto:ietf-http-wg-requ...@w3.org] On
Behalf Of Mark Nottingham
Sent: Monday, April 06, 2009 5:00
To: HTTP Working Group
Subject: Closing #63: RFC2047 encoded
Brian Smith wrote:
2008/11/26 Brian Smith [EMAIL PROTECTED]:
Under Apache CGI or mod_wsgi, in many situations you will get a
deadlock in this scenario.
It isn't 'many situations', it is a quite specific situation.
Right. I meant that it can happen quite often (every time) that situation
Graham Dumpleton wrote:
This following idea may not make much sense, but baby keeping
me up, its 4am and I am probably not going to get back to
sleep until I get this idea out of my head now.
:) I think you need to have a serious discussion with the baby. Maybe if
she got a job she wouldn't
Manlio Perillo wrote:
Brian Smith ha scritto:
We already have standard mechanisms for doing something
similar in WSGI: multi-threaded and multi-process WSGI
gateways that let applications block indefinitely while
letting other applications run.
Ok, but this is not the best solution
Graham Dumpleton wrote:
On 29/01/2008, James Y Knight [EMAIL PROTECTED] wrote:
a) One is to clarify this as a requirement upon the WSGI gateway.
Something like the following:
If the client requests Expect: 100-continue, and the application
yields data before reading from the input, and
I would like to see the following requirement added to the WSGI specification:
An application may only methods on environ[wsgi.input] before it returns its
response iterable, or from within an execution of its iterable's next() method.
In particular, the application iterable's close() method,
Graham Dumpleton wrote:
Effectively, if a 200 response came back, it seems to suggest
that the client still should send the request body, just that
it 'SHOULD NOT wait for an indefinite period'. It doesn't say
explicitly for the client that it shouldn't still send the
request body if
Manlio Perillo wrote:
Graham Dumpleton ha scritto:
On 27/01/2008, Manlio Perillo [EMAIL PROTECTED] wrote:
This is just a suggestion, but what about requiring that a WSGI
implementation calls the WSGI application only when all
the request body has been read?
Can't do that. The input
James Y Knight wrote:
On Jan 25, 2008, at 10:04 AM, Brian Smith wrote:
1. PEP 333 doesn't indicate that the size parameter for the read()
method is optional. Is it optional or required? If it is
optional, is the default value -1?
The spec says it's required (by virtue of not saying
1. PEP 333 doesn't indicate that the size parameter for the read() method is
optional. Is it optional or required? If it is optional, is the default value
-1?
2. What are the semantics of environ[wsgi.input].read(-1) when Content-Length
is provided? Is it guaranteed to return the entire
Ian Bicking wrote:
We encountered it with GData too, as it uses URLs like
/{http:%2f%2fexample.com}term/. But if you balance the {}'s
you can parse it out.
Unquoted curly braces are illegal in any kind of URI or IRI. Does GData
really require them to be unquoted?
- Brian
My application correctly responds to HEAD requests as-is. However, it doesn't
work with middleware that sets headers based on the content of the response
body.
For example, a gateway or middleware that sets ETag based on an checksum,
Content-Encoding, Content-Length and/or Content-MD5 will all
Chris McDonough wrote:
I have applications that do detect the difference between a
GET and a HEAD (they do slightly less work if the request is
a HEAD request), so I suspect this is not a totally
reasonable thing to add to the spec.
Yes, of course. In order to avoid doing unnecessary work
Graham Dumpleton wrote:
The issue here is that Apache has its own output filtering
system where filters can set headers based on the actual
content. Because of this, any output filter must always
receive the response content regardless of whether the
request is a GET or HEAD. If an
Graham Dumpleton wrote:
To quote, in 2 you said:
For a HEAD request, A WSGI gateway must not iterate
through the response iterable
I was presuming that this was saying that the WSGI gateway
should do this as well as changing the REQUEST_METHOD
actually sent to the WSGI application to
Manlio Perillo wrote:
As an example, I would like to use the code in the example for the
routing_args specification.
Manlio,
Are you planning to implement the routing_args specification directly in
NGinx's mod_wsgi? I think doing so is a really bad idea--routing_args
should be set and
Luis Bruno wrote:
Ian Bicking wrote:
But relating REQUEST_URI with SCRIPT_NAME/PATH_INFO is awkward and
having the information in duplicate places can lead to errors and
unclear situations if they don't match up properly.
I don't understand this argument. WSGI gateways just need to parse
Luis Bruno wrote:
Brian Smith wrote:
An ammendment that recommends, but does not require,
REQUEST_URI is a much better option.
Thereby forcing me to shop around for a WSGI server that
actually puts the recommendation into practice? Because I
want to keep my %-encoded characters? Which
Manlio Perillo wrote:
Graham Dumpleton ha scritto:
On 21/12/2007, Brian Smith [EMAIL PROTECTED] wrote:
The specification should then also explicitly say
that WSGI applications should not redirect logging
output to wsgi.errors or anywhere else.
In fact, if that was done, there would
Phillip J. Eby wrote:
There are other logging systems out there besides the Python
logging module -- and some of them are better for their
specific purposes.
If I was using a framework, I would use that framework's logging
package. But, I specifically want to limit my dependencies as much
Manlio Perillo wrote:
I can modify the code, so that:
- sys.stderr for the main interpreter goes to the main error log
- sys.stderr for subinterpreters goes to the error log declared in the
HTTP location where the WSGI application is mounted
I think that makes sense. To effectively handle
Graham Dumpleton wrote:
However there are some problems.
The log object has a fixed error level (NGX_LOG_ERR);
this means that every message logged using this object
will have this error level, even if I do, as example:
log.info('just an info message')
I'm missing the
Phillip J. Eby wrote:
Range support would be a good example of something
where an option isn't necessary, since properly-written Range
support in the server should be able to tell when the
application has already handled the necessary range-ing of
the output. Thus, having an option to
25 matches
Mail list logo
