On Wed, 2007-04-25 at 23:30 -0300, Sidnei da Silva wrote: > Subclass HTTPConnection and implement your own send()?
Yes. That seemed to be the best (or only) solution. I believe anyone using HTTPConnection for a POST where authentication may be required will have to do the same thing. > > On 4/25/07, Bart Whiteley <[EMAIL PROTECTED]> wrote: > > I have an issue with the following code in > > httplib.HTTPConnection.send(): > > > > # send the data to the server. if we get a broken pipe, > > # then close the socket. we want to reconnect when > > # somebody tries to send again. > > # > > # NOTE: we DO propagate the error, though, because we > > # cannot simply ignore the error... the caller will > > # know if they can retry. > > if self.debuglevel > 0: > > print "send:", repr(str) > > try: > > self.sock.sendall(str) > > except socket.error, v: > > if v[0] == 32: # Broken pipe > > self.close() > > raise > > > > I'm sending a POST request, with a somewhat large (3K) request body. > > The server requires authentication. If the request doesn't have the > > proper credentials, the server immediately sends a 401 response with an > > authentication challenge, and closes the connection without reading the > > request body. The server does this to protect against DoS attacks. > > When the client continues sending after the server closes the socket, > > the server sends a TCP reset, and the client usually gets a socket error > > of 104 (connection reset), but sometimes gets an error of 32 (broken > > pipe) instead. When I get a 104, I'm able to call getresponse(), and > > read the 401 response. Then I can retry the request with an appropriate > > response to the authentication challenge. When I get a socket error of > > 32, getresponse() throws an exception, so I don't have an authentication > > challenge to respond to. > > > > If I remove the "try:... except:" code above, so that self.close() does > > not get called on a broken pipe error, the http client code works > > nicely. In spite of the broken pipe, I can retrieve the response, and > > can retry the request with an appropriate authentication header. > > > > Is anyone aware of a way to work around this problem? > > > > _______________________________________________ > > Web-SIG mailing list > > Web-SIG@python.org > > Web SIG: http://www.python.org/sigs/web-sig > > Unsubscribe: > > http://mail.python.org/mailman/options/web-sig/sidnei%40enfoldsystems.com > > > > _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
