Problem with web2 HTTP server + authentication
Hello, I'm using a web2 server with Basic authentication provided by twisted.web2.auth.basic There are cases when PUT requests with attachments from a client time out, as following: 1. When the client issues the first PUT request, without an Authentication header, the server responds with a 401 Unauthorized before receiving all the attachment (I see this in a TCP trace made with ngrep). I want to ask if this is the right behavior, I saw that Apache waits for the entire attachment before replying with 401. 2. The client I used sends the next PUT request right after the attachment, without an \r\n separator, e.g. ...<closing-xml-tag>PUT /resource HTTP/1.1 Host: ... Is this normal ? Sometimes, when the attachment is bigger, some 10KB, the second PUT sent by the client (with the Authentication header present), is not entirely received by the server, which times out as it waits for the entire attachment, with size = ContentLength. I've printed the data received on the TCP socket, in the doRead() method of twisted.internet.tcp.Connection, and I think sometimes in the processing the HTTPChannel or HTTPFactory stops reading the data, it close the connection for reading, or something like that. Did anyone got a similar behavior? Thank you.
On May 31, 2007, at 11:09 AM, Mircea Amarascu wrote:
There are cases when PUT requests with attachments from a client time out, as following:
1. When the client issues the first PUT request, without an Authentication header, the server responds with a 401 Unauthorized before receiving all the attachment (I see this in a TCP trace made with ngrep). I want to ask if this is the right behavior, I saw that Apache waits for the entire attachment before replying with 401.
It is allowed to do so (and is doing so on purpose). But in this case, I believe it should be sending a Connection: close in the response.
2. The client I used sends the next PUT request right after the attachment, without an \r\n separator, e.g.
...<closing-xml-tag>PUT /resource HTTP/1.1 Host: ...
Is this normal ?
Yes, that is correct. But assuming the first statement is true (the first response properly included a Connection: close), the client should not be sending a second request on the same socket at all.
Sometimes, when the attachment is bigger, some 10KB, the second PUT sent by the client (with the Authentication header present), is not entirely received by the server, which times out as it waits for the entire attachment, with size = ContentLength. I've printed the data received on the TCP socket, in the doRead() method of twisted.internet.tcp.Connection, and I think sometimes in the processing the HTTPChannel or HTTPFactory stops reading the data, it close the connection for reading, or something like that.
If you can provide a minimal server that exhibits this problem and a packet trace of the interaction your client (or, a recipe to reproduce with a commonly available client), it would be helpful. James
participants (2)
-
James Y Knight -
Mircea Amarascu