203344 - Small optimisation in nsJARChannel: prevents creation/deletion of ZipItem object

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[Alfred Kayser]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030414
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030414

Patch follows

Reproducible: Always

Steps to Reproduce:

Comment 1

[Alfred Kayser]

Attachment: Simple and easy patch

Replace GetEntry with Available, no object creation/deletion,
just the content-length. As Available is here called directly 
after opening the stream the returned value is always the real content-length.

Comment 2

[Darin Fisher]

Comment on attachment 121677 [details] [diff] [review]
Simple and easy patch

yup, i like it.  this prevents the JAR channel from having to deal directly
with nsIZipEntry :-)

r=darin

Comment 3

[Alec Flett]

over to alfred

Comment 4

[Alec Flett]

Comment on attachment 121677 [details] [diff] [review]
Simple and easy patch

sr=alecf

I wonder if this will allow us to stop #including nsIZipEntry somewhere.

Comment 5

[Alfred Kayser]

Created bug 203627 for nsIZipEntry removal investigation.

How to apply the patch? Do I need to request CVS access, and then
cvs it into the tree?

Comment 6

[Mike Kaply [:mkaply]]

I'll check this in when the tree opens today.

Comment 7

[Mike Kaply [:mkaply]]

Checked in. Sorry it took me so long.

Comment 8

[[e-mail]]

Quick question: this doesn't depend on uncompressed entries, like Java does?

Comment 9

[Alfred Kayser]

No, this is about how to get the actual content length of the item,
and 'Available' just returns that (when called directly after opening).

Comment 10

[[e-mail]]

OK, I only ask because Java's InflaterInputStream.available() doesn't always.