267
267
self._curl_perform(curl, header, ['Expect: '])
268
268
except pycurl.error, e:
269
269
if e[0] == CURLE_SEND_ERROR:
270
# This has been observed when curl assumes a closed connection
271
# when talking to HTTP/1.0 servers, getting a 403, but trying
272
# to send the request body anyway. (see bug #225020)
273
code = curl.getinfo(pycurl.HTTP_CODE)
275
raise errors.InvalidHttpResponse(
277
'Unexpected send error,'
278
' the server probably closed the connection')
270
# When talking to an HTTP/1.0 server, getting a 400+ error code
271
# triggers a bug in some combinations of curl/kernel in rare
272
# occurrences. Basically, the server closes the connection
273
# after sending the error but the client (having received and
274
# parsed the response) still try to send the request body (see
275
# bug #225020 and its upstream associated bug). Since the
276
# error code and the headers are known to be available, we just
277
# swallow the exception, leaving the upper levels handle the
279
mutter('got pycurl error in POST: %s, %s, %s, url: %s ',
280
e[0], e[1], e, abspath)
282
285
code = curl.getinfo(pycurl.HTTP_CODE)
283
286
msg = self._parse_headers(header)