Closed
Bug 54381
Opened 24 years ago
Closed 24 years ago
ebay links using ISAPI.dll are broken
Categories
(Core :: Networking, defect, P3)
Tracking
()
RESOLVED
FIXED
People
(Reporter: law, Assigned: mscott)
References
()
Details
(Whiteboard: [rtm++])
Attachments
(5 files)
7.18 KB,
image/gif
|
Details | |
4.94 KB,
text/plain
|
Details | |
1.56 KB,
patch
|
Details | Diff | Splinter Review | |
2.41 KB,
patch
|
Details | Diff | Splinter Review | |
2.41 KB,
patch
|
Details | Diff | Splinter Review |
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.
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
Comment 4•24 years ago
|
||
I'm getting this problem with every eBay item page as well.
Assignee | ||
Comment 5•24 years ago
|
||
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
Assignee | ||
Comment 6•24 years ago
|
||
Assignee | ||
Comment 7•24 years ago
|
||
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)....
Comment 10•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
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.
Comment 12•24 years ago
|
||
It also does not work in W2K.
Comment 14•24 years ago
|
||
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
Comment 15•24 years ago
|
||
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 → ---
Reporter | ||
Comment 16•24 years ago
|
||
Ditto for me (actually, I logged in, but ran into the problem when I tried removing some watched items). Windows98 2000100908 build.
Comment 17•24 years ago
|
||
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?
Assignee | ||
Comment 18•24 years ago
|
||
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....
Assignee | ||
Comment 19•24 years ago
|
||
Assignee | ||
Comment 20•24 years ago
|
||
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
Comment 22•24 years ago
|
||
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.
Comment 23•24 years ago
|
||
argh... seems like .exe's can do the same behaviour (application/x-msdownload) See bug 55509.
Comment 24•24 years ago
|
||
*** Bug 55509 has been marked as a duplicate of this bug. ***
Comment 25•24 years ago
|
||
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
Comment 26•24 years ago
|
||
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)
Assignee | ||
Comment 27•24 years ago
|
||
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...
Assignee | ||
Comment 28•24 years ago
|
||
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...
Assignee | ||
Comment 29•24 years ago
|
||
Assignee | ||
Comment 30•24 years ago
|
||
Assignee | ||
Comment 31•24 years ago
|
||
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.
Comment 32•24 years ago
|
||
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
Comment 33•24 years ago
|
||
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.
Comment 34•24 years ago
|
||
This looks reasonable... (sr=rpotts)
Assignee | ||
Comment 35•24 years ago
|
||
*** Bug 53069 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 36•24 years ago
|
||
changing rtm need info to rtm+ now that the reviews are in order. r=gagan sr=rpotts
Whiteboard: [rtm need info] → [rtm+]
Comment 37•24 years ago
|
||
Note to QA: pls verify http://bugzilla.mozilla.org/show_bug.cgi?id=53069's case when this bug is marked fixed.
Assignee | ||
Comment 39•24 years ago
|
||
I've verified that this fix also covers the www.techfed.com case which I marked this bug a dup of.
Assignee | ||
Comment 40•24 years ago
|
||
fix checked into tip and branch.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 41•24 years ago
|
||
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
Comment 42•23 years ago
|
||
qa to me.
You need to log in
before you can comment on or make changes to this bug.
Description
•