BadStatusLine("HEAD / HTTP/1.1")

[KeithHanlan]

We use bottle as a convenient wrapper for a transient service. (We have client code in multiple languages and this service lets us have a single implementation for this functionality.)

Client bootstrap code starts a bottle application and enter a loop where it sends a HEAD / request until it gets a good response status.

An abbreviated version of this check looks like:

while not bottle_up:
    try:
        conn = http.client.HTTPConnection(host)
        conn.request('HEAD', '/')
        status = conn.getresponse().status
        conn.close()
    except http.client.BadStatusLine as bsl:
        ...
    bottle_up = status in [http.client.OK, http.client.FOUND]

Once in a very long while, getresponse().status raises BadStatusLine with

HEAD / HTTP/1.1

where the original request is included in the response and the HTTP version is missing.

We expect to see something like:

HTTP/1.1 200

We have only ever seen this happen in our regression machinery where we have multiple testcases executing in parallel.

Now this is, admittedly, an old version of 0.13-dev and I am in the process of updating to a newer version of either stable or dev. But I reviewed bottle's open and closed issues and see no mention of BadStatusLine so I am wondering if this was ever seen by other users. Conceivably it is a bug in the http.client library but this is doubtful since we have encountered this problem with several different versions of python3.

Thanks for the great tool. Apart from this intermittent issue, bottle has been rock solid and a joy to work with.

[defnull]

That's a very odd error and I have no idea how that is even possible. The code that sets the status line is not very complicated and did not change recently: https://github.com/bottlepy/bottle/blob/master/bottle.py#L1714 Setting a status that does not start with a numeric code should not be possible.

[KeithHanlan]

Thank you for your reply @defnull.

I agree that this is quite peculiar. I will update to the latest 0.13-dev version and monitor it closely for a few weeks. If the problem does not recur, then I will assume that it was magically "fixed" sometime in the past four years (our version dates to May or early June 2016). If it does recur, then I will instrument the http.client code and gather more data. You're welcome to reject this ticket. I'll let you know if I find a smoking gun.

Best regards from Ottawa, Keith

[defnull]

Please reopen if you find more information.