89701 - We should not be using HTTP 1.1 in libxpnet

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Syd Logan]

Gagan says we should be using 1.0.

Comment 1

[Syd Logan]

reassigning to me

Comment 2

[Gagan]

If we know for sure that all the servers that libxpnet will be talking to is 1.1
compliant then this is ok, however knowing the kinda problems we've seen with
1.1 and proxies I'd say we should be careful and just use 1.0. This won't hurt
us one bit but would prevent any random 1.1 specific issues from hurting the
otherwise simple implementation of HTTP in libxpnet. 

Comment 3

[Gagan]

Attachment: patch to fix http/1.1 to http/1.0

Comment 4

[Sean Su]

you should also update the #ifdef'ed out main code too:
 
http://lxr.mozilla.org/seamonkey/source/xpinstall/wizard/libxpnet/src/nsSocket.cpp#566

Comment 5

[Daniel Veditz [:dveditz]]

Comment on attachment 61137 [details] [diff] [review]
patch to fix http/1.1 to http/1.0

sr=dveditz

Comment 6

[Gagan]

Attachment: patch for nsSocket's use of HTTP as well.

This is needed in addition to the first patch.

Comment 7

[Gagan]

Thanks ssu. Didn't notice another one sneak by... :) Fixed in this second patch.

Comment 8

[Sean Su]

Comment on attachment 61148 [details] [diff] [review]
patch for nsSocket's use of HTTP as well.

r=ssu

Comment 9

[Daniel Veditz [:dveditz]]

Comment on attachment 61148 [details] [diff] [review]
patch for nsSocket's use of HTTP as well.

sr=dveditz

Comment 10

[Sean Su]

adding keyword

Comment 11

[Sean Su]

Comment from Samir:
  As far as I recall the reason I implemented it as HTTP/1.1 is because:
  (a) we are guaranteed byte ranges (I think), and
  (b) we use our own servers which support HTTP/1.1 and this is not some generic
  library that needs to be tested against and subjected to varying server 
  conditions since the vendor controls it.
  ~Samir

Comment 12

[Curt Patrick (gone)]

Marketing has expressed some interest in this issue so I'm cc'ing Gregg.

Comment 13

[Gagan]

a. You can do byte-ranges with HTTP/1.0 as well. It totally relies on the server
(and inbetween proxies) supporting it. 

b. We may have control over our servers that may be tweaked to do custom
responses BUT we have no control over the several different types of proxies out
there that have their own interpretation and expectations of HTTP/1.1 compliance. 

If we are not HTTP/1.1 compliant why advertise it as such? I can not think up of
anything more than what you can achieve with just HTTP/1.0. Can you?

Comment 14

[Samir Gehani]

Oh, I didn't realize you could request byte ranges with HTTP/1.0 and was told
the same.  The HTTP/1.0 RFC doesn't reflect that you can request byte ranges. 
Maybe HTTP/1.0 implementations support byte ranges.  Gagan probably has more
data in this area.  At any rate, I guess the range request header will be
ignored by HTTP/1.0 server implementations so it won't hurt.  I can see the
rationale to announce we are talking HTTP/1.0 rather than HTTP/1.1.

Comment 15

[Bill Benetti]

I also was not aware of ability for http 1.0 to specify byte offsets for files.
We're using various versions of Apache and none of my modifications deal with
custom responses.  It sounds like 1.0 will do everything we need it to.  Let me
know if there are any changes I need to make on the server side.

Comment 16

[Gagan]

FWIW Netscape 4.x (with HTTP/1.0) supported byte-range. Considering the
significance this bug has on the success of the installer I am clearing the
Future milestone and nominating for 0.98

Comment 17

[Curt Patrick (gone)]

So that's why this isn't showing up on my queries.  Assigning to myself.

Comment 18

[Curt Patrick (gone)]

I agree that this should be targetted for 0.9.8.  

Actually, the fix is quite straightforward.  QA has the bigger job.  We need to
test two protocols (ftp and http) against both proxy possibilities (1.0 and
1.1).  So 4 test cases need supported.  (Samir is particularly concerned that
there may be a problem when we try to do failure recovery using http 1.0 through
a 1.0 proxy server since that proxy server might not support byte ranges?)

I guess active vs passive ftp might be another issue but Samir and I (I use the
phrase "and I" in a purely figurative sense) couldn't come up with any testing
requirements for this.  If someone thinks differently, speak up.

So the test matrix will be to test failure/recovery in the following cases:
- http through a 1.1 proxy server
- ftp  through a 1.1 proxy server
- http through a 1.0 proxy server
- ftp  through a 1.0 proxy server
- and, I suppose, both http and ftp through no proxy server, though if it works
through a proxy server it shouldn't have any problems without one!

Grace is preparing to support this test matrix.  I believe that the next step is
for me to provide her with an installer which has the above http 1.0 patch
applied and let her bang away on it until we're confident that it behaves properly.

Comment 19

[Olivier Mengué]

You should add to the matrix to test for proxy authentication.

Actually "407 Proxy Authorization required" is not reported to the user.
I'll post a bug for that. 

Comment 20

[Curt Patrick (gone)]

Grace did some testing with this to make sure the download still works, even if
interrupted.  She says it looks go so I've checked in the patch.

Comment 21

[Grace Bush]

this is has not been tested via proxy servers- that is still not working- I 
verified that download takes place using the http 1.0 protocol (over Win only)

We may have to leave this bug open until proxy bugs fixed- I can add the 
dependencies

Comment 22

[Grace Bush]

leaving this bug resolved/fixed until it can be tested using a proxy server

Comment 23

[Grace Bush]

verified code fix