bzr get fails without Content-type on inventory.knit file

On Tue, 2006-09-26 at 15:56 +0000, Daniel Dehennin wrote:
> Public bug reported:
>
> Cherokee do not send Content-Type when it doesn't know the file type.
>
> bzr produce an error:
> bzr: ERROR: Invalid http Content-type "" for http://www.asgardr.info:8080/~nebu/archives/dvc.dev/.bzr/repository/inventory.knit: Missing Content-Type
>
> Maybe bzr should assume application/octet-stream if there is no Content-
> Type ?

Is it sending:

HTTP/1.1 200 OK\r\n
Content-type: \r\n
Content-length: 12\r\n
...

or
HTTP/1.1 200 OK\r\n
Content-length: 12\r\n
...

rfc2616 says:
       Content-Type = "Content-Type" ":" media-type
       media-type = type "/" subtype *( ";" parameter )
       type = token
       subtype = token

That is, an empty content-type header is illegal. An ommitted one is ok (but undesirable for a variety of reasons).

-Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

As you can see in the attached dump, there is no Content-Type at all, not an empty one.

Regards

Marking this as low priority, but to fix it should be moderately simple. Specifically the code is in:
bzrlib/transport/http/response.py around line 255.
We need 'Content-Type' because we check to see if the returned type is multipart. However, if there is no 'Content-Type' we could just assume it cannot be multipart. I'll post a patch which may fix this, though I haven't tested it or written any tests for it.

It was small enough that I went ahead and fixed it, and associated the branch with the fix.

I will write the tests for that. Fixing that bug with associated tests was on my TODO list anyway, thanks for providing the patch :-)

did you see that I already wrote a test for it, along with the fix, and submitted it to the mailing list? I don't want you to end up having to do extra work.