691344 - stream->end is incorrect for streams of compressed data

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[David Fooks]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.187 Safari/535.1

Steps to reproduce:

Call NPN_GetURLNotify requesting a URL with a gzip compressed response body.


Actual results:

stream->end is equal to the content-length which is the length before the message was uncompressed. (If I want content-length I can extract it from the stream->headers)


Expected results:

stream->end should be the length of the stream (which is now uncompressed). If you look at the documentation for stream->end (https://developer.mozilla.org/en/NPStream) "Offset in bytes of the end of the stream (equivalent to the length of the stream in bytes). Can be zero for streams of unknown length, such as streams returned from older FTP servers or generated "on the fly" by CGI scripts." Then this is the behavior you would expect.

I can't think of a single use case where you would want to have the length of the compressed stream when you are given the uncompressed stream.

Comment 1

[BMO Automation]

Resolving as wont fix, plugin support deprecated in Firefox 85.