Re: [PATCH] web: http: Accept blank Content-Type headers.

[Thompson, David]

Apologies for the previous email.  I seriously botched some keystrokes.

On Mon, Jul 27, 2015 at 5:05 PM, Mark H Weaver <address@hidden> wrote:
> David Thompson <address@hidden> writes:
>
>> I encountered a bug in the HTTP header parsing bug when trying to
>> download a file via Guix.  The response had a Content-Type header, but
>> with no value, like so:
>>
>>     Content-Type:
>>
>> From reading the W3C spec[0], an unknown Content-Type header can be
>> treated as if it were an application/octet-stream type.
>
> An empty string is not merely an "unknown" Content-Type header.  It is
> blatantly invalid syntax.  It would be good to contact the web site
> owner and ask them to fix it.

Yes, I have done so.  I haven't heard back yet.  I hope they take this
seriously.

> Since web clients seem to accept just about anything these days, and web
> servers have adapted to this by producing garbage, it may be that we
> need to add a "permissive" mode that sifts through the garbage and uses
> heuristics to try to make some sense of it.
>
> However, I'm not sure it makes sense to handle this particular case of
> an empty Content-Type header specially, at that this place in the code.
> Do we have any other examples of this particular error?

No, just this one.  I think getting rubygems.org to fix the issue will
be better than adding a special case to the HTTP header parser.

> I realize that it's more work, but I would prefer to retain a mode that
> reports errors (possibly making a few compromises for very widespread
> errors), and then to somehow implement another mode that accepts
> *anything* and does its best to make sense of it.
>
> What do you think?

Yes, that makes sense.  I don't have the drive to attempt that right
now, but thanks for sharing your thoughts about this.

Thanks!

- Dave