Closed Bug 54381 Opened 24 years ago Closed 24 years ago

ebay links using ISAPI.dll are broken

Categories

(Core :: Networking, defect, P3)

x86
Windows 98
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: law, Assigned: mscott)

References

()

Details

(Whiteboard: [rtm++])

Attachments

(5 files)

Go to some (any?) ebay item.  Click on the "watch this item" link (in upper
right).  When you click the "Watch Item" button on the generated page, you get a
Download dialog that reports you are trying to load data of type
application/x-msdownload.

After this happens, *any* ebay link that uses isapi.dll cgi scripts generate the
same response (e.g., My eBay, searches, etc.).
I'm seeing this, too.

I can't get through to *any* of the Ebay item pages.
Attached image GIF of the error
My Redhat seems to handle the page fine.   My Win98 system gives me the download
dialog.

Adding mscott to CC list per IRC discussion.  - Related to bug 43556 ?
OS: other → Windows 98
I'm getting this problem with every eBay item page as well.
I'm not sure how to fix this bug....I do think it's an RTM type bug since ebay
is a top 100 bug.

Gagan, here's what I see in the debugger: when we run the url after you click on
the button for this url, we process the response headers and don't apparently
receive a content type back. (The http status code == 200 if that makes a
difference). So the http response::GetContentType has an empty string for the
content type header. It ends up getting the content type from the mime service.
Since the file ends with .dll, we assume a content type for this extension.
Callers (in this case the uriloader) asking for the content type of the channel
are given this information. Of course mozilla can't handle .dll so we throw up
the helper app dialog.....

If ebay doesn't give us a content type header and if they use .dll at the end of
the url then both our content type guessing mechanisms fail!

I wonder if we are in a state where we are calling OnStartRequest from http
before we've really parsed all the headers out. Or is ebay really not sending a
content type for this url??
Keywords: correctness, rtm
Here's an http log showing the response when we fetch
http://cgi1.ebay.com/aw-cgi/eBayISAPI.dll
this url is fetched after we post the login data....

As you can see, right after the date header, it looks like the http server spits
out an emtpy CRLF so we assume there are no more headers left to parse and the
on start request gets fired.

I'm wondering if there aren't more headers in there that we aren't getting.

It seems odd that this URL only has only 2 http headers (server and date)....
This is a very new bug.  I'm almost positive M17 worked.
*** Bug 55044 has been marked as a duplicate of this bug. ***
mscott: your hypothesis is totally possible. I am also noticing a huge set of
events out of order. And there are some possible suspects (dougt's events
changes, and HTTP cache changes) These are manifesting themselves in various
bugs from crashers to this one.
I just wanted to add that you cannot bid on any items in ebay using
Netscape6/Mozilla, so this is probably a higher priority than P3 (at least P2).

Also, I'm using NT and seeing this, so Windows98 for platform seems wrong.

Definitely worked in PR2 and probably is an even more recent regression.
It also does not work in W2K.
raising severity of this bug.
Severity: normal → major
As suspected, this bug was also a victim of the plevents changes that dougt had
landed. (see bug 54371) Doug landed part of the changes of that bug which
affected this and several other bugs. So this is now fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Can't log in to myEbay using the 10/9 branch build on NT. I get the unknown
content type dialog for application/x-msdownload. Reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ditto for me (actually, I logged in, but ran into the problem when I tried
removing some watched items).  Windows98 2000100908 build.
Hmmm.. This works fine for me on Linux. Seems like the possible entry of dll's
mime type being in windows registry could be throwing us off. I am not sure how
we could resolve this. Mscott: I have verified that there are no additional
headers being supplied for that last transaction. Let me know if there is
something I can do to help with the networking part, but this is pretty much a
case with making guesses of the mime type. We could add checks (like 4.x) for
specific cases of .dll extension (with a no mime-type specified)Would that be a
reasonable thing, mscott?

please read my analysis above as to why this is a windows only bug....

Hmmm, maybe we could do that? When downloading an http document with a .dll
extension, don't assume it's really a dll if a content type isn't specified?

I'm starting to think for rtm such a hack may be our only choice....
I've attached a fix for this problem based on what Gagan and I were talking
about with hard coding a special case for http urls that end in .dll where the
server doesn't specify the content type.

Please note a couple of things:
1) This bug is actually 100% reproduceable on ALL platforms. On windows, since
we find a mime type for .dll, we end up throwing a ucth dialog. On linux and
Mac, we can't figure out the content type for .dll so http was setting it to be
application unknown. This causes the page to be loaded as plain text in the browser.

Both behaviors are incorrect.

The url really results in text/html content. But the file ends in .DLL and for
this particular URL, eBay is not sending a content type. If you try to just
login to my ebay, they actually do send a content type and this works on all 3
platforms for me.

It's just certain situations while browsing through the site, they don't return
a content type.

The fix is pretty simple,
in nsHTTPChannel::GetContentType --> if we didn't get a content type from the
headers AND if the url end with a file extension of "dll", then set the content
type to "text/html".

In all other cases, fall back to the mime service and let it figure out the
content type based on the file extension.

I've tested this fix on Linux and Windows so far.

Gagan, can you remember any other special cases for extensions like this one
that 4.x hard coded for?

I also need a r=gagan and a sr. I'd like to get this to the attention of PDT
today if we can get the reviews lined up in time...
Assignee: gagan → mscott
Status: REOPENED → NEW
putting on the [rtm need info] radar.
Whiteboard: [rtm need info]
I have two concerns regarding the patch. 1. There is a very valid possibility of 
this check being beyond HTTP so I would consider putting this on MIMEService 
(which is where I had started fixing this) 2. The check for URL may fail (if 
there is a URI without a URL) and so in the else part we should still check for 
the raw extension. (see how MIMEService implements this) I'll swing by your cube 
to see if you have any questions. Thanks. 
argh... seems like .exe's can do the same behaviour (application/x-msdownload) 
See bug 55509. 
*** Bug 55509 has been marked as a duplicate of this bug. ***
I could be wrong, but I don't see any reference to an .EXE file in bug 55509
The URL that is in question is:
http://www.tv.aol.fr/cgi-bin/aoltv.dll?tvgroupe
Doh... I got the wrong bug number there. The dup is marked correctly for the dll 
case (55509) but I do have a bug that shows the same behaviour for exes. (let me 
find that again)
I actually don't believe any of this belons in the mime service =). If we put it
in the mime service then we lose the ability to properly determine the content
type of .exe and .dll files!!

The problem with this bug is some websites use a login procedure involving
isapi.dll and they aren't returning a content type of text/html for a url that
includes this file.

I think the change needs to be isolated to http.

I'm open to extending the if clause to include .exe. Let me look at the example
exe url to make sure they are really spouting text/html there too...

As an aside, the following url that someone posted earlier as part of Bug #55509
which got marked a dup of this:

http://www.tv.aol.fr/cgi-bin/aoltv.dll?tvgroupe

works correctly with this patch. It doesn't use .exe, it uses .dll. So it's
fixed by the same patch. We don't need another if clause...

I don't know why my patch just got double posted oh well.

After talking some more with Gagan, we concluded that it was incorrect to force
the content type to text/html when we see a http url with a .dll extension
without a content type. 4.x hard coded the content type to unknown in this case.

But this didn't work in 6.0 on the eBay url in this bug. That's because there
was a bug in our unknown content type decoder which trys to sniff the data
stream to guess the content type when the content type = unknown.

The only HTML tag in the first 1024 characters of the document is a BODY tag:
<BODY ....>. Our decoder was looking for <HTML, <SCRIPT, <TITLE or <FRAMESET. So
it wouldn't guess that this was HTML.

I added a fix to the decoder to search for <BODY tags as well.

I then changed the http channel to skip the mime service lookup if we have a url
with a .dll extension and to fall back and set the content type to unknown.
Later on, when the decoder is invoked we now correctly determine that it's
really text/html.

Both the aol and the ebay link now work correctly on linux and windows for me.

Gagan says he has a similar bug somewhere for .exe files that result in
text/html content. So we'll probably want to expand this if clause to include
.exe as well. I'm going to hold off on posting that change until we have an
example url.

Gagan, can I get a r=gagan on this? I'll ping rpotts for a super review.
This looks ok to me. Be aware that this still misses the check in case the uri 
isn't a url. (not a big deal for rtm but we should at least throw in an assert 
to catch that later) Other than that, r=gagan 
argh. I can't find the other bug that has this problem with .exe urls. For now I 
guess this check is sufficient. thanks for fixing this mscott.
This looks reasonable...  (sr=rpotts)
*** Bug 53069 has been marked as a duplicate of this bug. ***
changing rtm need info to rtm+ now that the reviews are in order. 
r=gagan
sr=rpotts
Whiteboard: [rtm need info] → [rtm+]
Note to QA: pls verify http://bugzilla.mozilla.org/show_bug.cgi?id=53069's case
when this bug is marked fixed.
rtm++
Whiteboard: [rtm+] → [rtm++]
I've verified that this fix also covers the www.techfed.com case which I marked
this bug a dup of.
fix checked into tip and branch.
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
verified on branch:
Win98 2000101608

techfed site isn't responding for me but mscott already tested it apparently

this needs verified on trunk
Keywords: vtrunk
QA Contact: tever → benc
qa to me.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: