59016 - jpg don't display

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P3)

Description

[Richard Solomon]

I don't know if it's html compatability but the jpg display correctly in
Netscape 4.7 but not here.

Comment 1

[Doron Rosenberg (IBM)]

<IMG SRC="http://features.yahoo.com/model/smith/anna3.jpg" WIDTH=244 HEIGHT=327
                  ALIGN=bottom>

this html is illegal, should be all in one line.

Comment 2

[Gilles Durys]

#00HTTP/1.0 200 OK Last-Modified: Tue, 06 May 1997 01:15:37 GMT Content-Type: image/jpeg
Content-Length: 17830 Expires: Fri, 24 Dec 1999 23:59:59 GMT ÿØÿàJFIFHHÿíÞPhotoshop 3.08B etc...

This is what you get when trying to load the url

Comment 3

[Doron Rosenberg (IBM)]

reopneing, i had the image cached, which is why it showed for me locally.  

Comment 4

[tor]

HTML doesn't care about whitespace.

There's extra bytes preceeding the "HTTP" in the response which are causing
problems for mozilla.  Reopening and reassigning to networking.

Comment 5

[tor]

Changing assignment/qa to match component.

Comment 6

[[e-mail]]

The remote server (features.yahoo.com) or some sub-process there is broken,
indepedently confirmed that it writes gibberish before returning an HTTP reply
for the requested image. At that point all you can do is assume it speaks
HTTP/0.9, which it doesn't. Not Mozilla's problem.

Comment 7

[tor]

While it seems the server has some issues, Netscape 4.x manages to recover
gracefully and display the image.

Comment 8

[Darin Fisher]

added keyword 4xp.

Comment 9

[Darin Fisher]

->me

Comment 10

[Darin Fisher]

this will be fixed once my changes for bug 76866 land.

Comment 11

[R. Solomon]

This bug was fixed about two or three weeks ago. It seems to have regressed
since then. It only worked once during that time frame.

Comment 12

[benc]

Do we need to invalidate this or take it as 4xp?

Comment 13

[Darin Fisher]

we could easily sniff the first data packet for HTTP and discard any leading
bytes up to some maximum number of bytes... say 8 or some such small number.

Comment 14

[Darin Fisher]

i've also seen problems with proxy servers sending erroneous bytes before the
HTTP as well... so, this solution may fix more than just this server.

Comment 15

[Darin Fisher]

Attachment: v1.0 solution

Comment 16

[Darin Fisher]

Attachment: v1.1 revised LocateHttpStart method

Comment 17

[Gagan]

Comment on attachment 47925 [details] [diff] [review]
v1.1 revised LocateHttpStart method

r=gagan

Comment 18

[Gagan]

Comment on attachment 47925 [details] [diff] [review]
v1.1 revised LocateHttpStart method

r=gagan

Comment 19

[Darin Fisher]

Attachment: v1.2 revised LocateHttpStart comments per discussion with dougt (over AIM)

Comment 20

[Darin Fisher]

fixed-on-trunk

Comment 21

[Daniel Mario Vega (Restore MNG Support --> #18574)]

I still can not see the images on the reported URL. I did reload and
Shift-Reload. I tested it with and without proxy. BuildID 2001091909 on Linux

Comment 22

[Darin Fisher]

i just tried build 2001-09-18/12 and 2001-09-14/08 under linux and both work.
i haven't tried the 9/19 build, so perhaps this is a very recent regression?!?

Comment 23

[Daniel Mario Vega (Restore MNG Support --> #18574)]

I have investigated this problem a little more. My ISP is using some kind of
transparent proxy (NetCache NetApp/5.1R2D2). I can not see the images in the
reported URL because this proxy is sending incorrect data.

Mozilla is working fine.

Comment 24

[Darin Fisher]

makes sense.. thanks for investigating.

Comment 25

[Tom Everingham]

verified 01/14/02 builds  WinNT4,  Linux rh6,  Mac osX