Bug#126041: HTTP content-type of *.diff.gz at packages.d.o

[Nikolaus Schulz <microschulz@web.de>]

Hi,

AFAICS there has been no discussion about this on the lists.  

    Problem description: packages.debian.org/${PACKAGE} links to source
package files.  If the client accepts compressed content, the web server
serves ${PACKAGE}.{diff,orig.tar}.gz as text/plain, with HTTP
"content-encoding: gzip".  AFAIUI this tells the client to uncompress
the file, independent of the file extension.  E.g. Opera does this,
while Firefox does not.  An uncompressed diff is unusable with
dpkg-source.

    Now there is this ancient bug [1] open (#126041, Dec 2001).  OTOH, there
has been the even older #119462 [2], where the submitter complained that
the files were *not* transmitted as plain text, so they could not be
viewed within the browser.  This bug has been closed, claiming it has
been fixed.  This suggests that the current behaviour is intended,
though I hope it isn't.  Could someone please clarify this?  Or even
better, could someone fix it?  

    I'm appending a comment [3] from Yngve Nysaeter Pettersen, an Opera
developer, about this issue.  I guess HTTP experts may feel free to skip
it. 

> The server is probably sending the response as something that looks like this
> (for a file named file.txt.gz) :
> 
>   Content-Type: text/plain
>   Content-Encoding: gzip

I can confirm this for packages.{,qa.}debian.org.

> To a client this means that the content is text/plain, but that it is delivered
> gzip compressed, and may be stored in that format internally, but when the
> client displays the file to the user it must decompress the file first. Both
> display on screen and download/save to file is considered display. The _only_
> exception we make is for gzipped tar files.
> 
> The correct would in this case have been
> 
>   Content-Type: application/x-gzip
> 
> The first example would be correct if the server got a request for file.txt, and
> it had both file.txt and file.txt.gz available (and the client indicated support
> for gzip encoding).
> 
> For more information about Content-Encoding see RFC 2616 sections 7.2.1 and
> 14.11.
> 
> The problem (I assume) is that the server's content negotiation algorithm sees
> the gz extension in the selected file and while it knows that it belongs to the
> application/x-gzip content-type, it ignores the actual client request's
> extensions because it also know that this extension is used for gzip
> content-encoding, and then looks to see if there is an extension in front of the
> gz extension that it knows, and in this case it finds the .txt extension which
> it knows translates to the text/plain type and picks that as the content-type.
> 
> In cases such as the above example the content-encoding aspect should have been
> ignored.
> 
> If that is the case, this is entirely a server-side bug, and should be reported
> to the vendor.

So, if he's not plain wrong: does someone care?  That would be great.  

Thanks,
Nikolaus 

PS. Yes, Opera is my favourite browser.  :-/

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=126041
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=119462
[3] http://tinyurl.com/px8ja