Closed Bug 76816 Opened 24 years ago Closed 7 years ago

View Source shows the entire multipart response on a Bugzilla buglist (was: tries to DL Bugzilla buglist as multipart/x-mixed-replace)

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: tarahim, Unassigned)

References

(
URL
)

Details

Attachments

(2 files)

Example of downloaded content showing multipart chunks
17.58 KB, text/plain
Details
IE <-> Bugzilla buglist session as seen by sniffer
43.63 KB, text/plain
Details
2001041908 (and 0417) mac trunk. Goto URL. View Source. Result: A blank window covering a file save dialog, indicating that the file MIME type is multipart/x-mixed-replace. Expected result:The source should be displayed just like other pages. Could be dependent on bug 76657, so I will test again in the next build.
seeing this on linux as well : OS,Platform ->all
OS: Mac System 9.x → All
Hardware: Macintosh → All
Setting to 1.0.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
A: The unwanted download dialog: This is basically the same symptom as seen in bug 77337, "view-source: does not allow viewing of many text files", ASSIGNED. According to NN 4.77's Page Info, the buglist is sent with the Content type text/html, which should be working in view-source; in actual fact it is sent in chunks, which likely explains why Moz thinks it is multipart/x-mixed-replace. The patches in Bug 77080, "Show application/x-javascript in browser window instead of trying to download", FIXED, may be suggestive... B: View source should not be going out on the network again Aside from that, though, view-source should in *all* cases, regardless of content type, be displaying what is already in the cache for a given URL, rather than fetching it again: see bug 55583, "view-source should show original source (use cached source)" and its blocker, bug 40867, "need means to reuse/reload current page without refetching from server". But see section C; it appears that section A is more relevant; after saying [Ok] to the download, the server response to the URL is saved to a file, but no new download takes place. C: The downloaded content: If the download is allowed to proceed, two things are immediately noticeable: 1. Nothing is sent or received over the network (no Rx or Tx on Modem or Router). 2. The file containing the download contains three instances of "--thisrandomstring" and two instances of "Content-type: text/html"; the response for the URL *was* multipart. So view-source should probably show at least both chunks of the response, and probably the "--thisrandomstring" delimiters as well. If not, only the last chunk, which is a text/html response, should be passed to the view-source code. Tested with 2001-05-20-22 on WinNT. Attachment to follow containing contents of buglist download for view source bugs since the beginning of 2001. In summary: s/the Today's bug page/Bugzilla buglist/ -- same problem no matter what the buglist is. Is this a Networking bug, another mainfestation of bug 77337, or a multipart-parsing bug?
Summary: View Source tries to DL the Today's bug page as multipart/x-mixed-replace → View Source tries to DL Bugzilla buglist as multipart/x-mixed-replace
*** Bug 83859 has been marked as a duplicate of this bug. ***
*** Bug 85153 has been marked as a duplicate of this bug. ***
*** Bug 88812 has been marked as a duplicate of this bug. ***
*** Bug 90203 has been marked as a duplicate of this bug. ***
*** Bug 93151 has been marked as a duplicate of this bug. ***
I see this also when trying to view source on a bugzilla query response
*** Bug 98853 has been marked as a duplicate of this bug. ***
*** Bug 100436 has been marked as a duplicate of this bug. ***
QA Contact: bsharma → moied
*** Bug 103152 has been marked as a duplicate of this bug. ***
*** Bug 104574 has been marked as a duplicate of this bug. ***
*** Bug 104736 has been marked as a duplicate of this bug. ***
*** Bug 105635 has been marked as a duplicate of this bug. ***
*** Bug 111814 has been marked as a duplicate of this bug. ***
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Another page where a similar thing happens: http://computer.history.museum/bldg/ It claims that this is an unknown MIME type. Mozilla is getting to be a really nice browser now, but one of the handful of really annoying things about it is the extreme flakiness of the "View Source" feature. If you can get this working reliably, Mozilla will be really great!
This seem to have a lot of duplicates. Moving to 0.9.9.
*** Bug 134270 has been marked as a duplicate of this bug. ***
*** Bug 134956 has been marked as a duplicate of this bug. ***
No one seems to have considered a basic question here. "What should view-source show on a multipart page"? All the data as it came from the server raw? (That could run into issues if one of the parts was, say, a gif or worse yet if the multiple parts are all text but in different encodings.) The source of the last part? (This could be quite interesting to do in the current architecture). The source of the first part? The source of the "current part" (what if the user hit 'stop' while the multipart doc was loading?) We should decide this question first and foremost.
#23 How do other browsers handle this? How did earlier Netscape versions?
> How do other browsers handle this? How did earlier Netscape versions? Tested NS 4.76 on Linux and IE 5.0 on Solaris (which is pretty much identical to IE 5.0 on Windows). That's all I have to test: 1) Load a buglist. Wait for it to completely load. Then view source: NS4 -- shows source of last part IE5 -- shows first 1/5 of the source of the last part (and it was a fairly small query -- 20 bugs or so) 2) Load a buglist. Hit stop on the "Please stand by..." screen NS4 -- crash IE5 -- never shows that screen (looks like broken multipart/x-mixed-replaced handling) More testing of other versions of IE would be nice.
IE 6 / Win: 1) Whole last part. 2) I couldn't get it to load any "Please stand by..." page. It always seems to go directly to the bug list. Unless I'm missing something. IE 5.1 / Mac Classic: 1) Whole last part as well. 2) Same... Is it a bug of IE 6 and IE 5.1/Mac that they don't show up any "Please stand by..." page?
> I couldn't get it to load any "Please stand by..." page. It always seems to > go directly to the bug list. Make sure you do a big query. Eg, try to get a list of all resolved or verified bugs. If you still don't see the "Please stand by..." page, that's a bug in IE.
http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=1&votes=&chfield=%5BBug+creation%5D&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Browser&product=MailNews&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time IE6: 1) Load a buglist. Wait for it to completely load. Then view source: IE6 -- shows complete HTML source of the bug list 2) Load a buglist. Hit stop on the "Please stand by..." screen IE6 -- never shows the standby screen. Sniffer shows that the server sent the page as text/html in the beginning - it probably detects IE by looking at its user agent string and doesn't bother with multipart. Boris, Sören: It would indicate that IE test is invalid since the document that Bugzilla offers to IE is not multipart anyway.
#28, #29 You're absolutely right. IE isn't getting any multipart version, at least not IE6.
URL to test multipart stuff on: http://www.zbarsky.org:8000/cgi-bin/testMultipartData3.pl It looks like IE5.0/Solaris just flat out does not support multipart content. I seem to recall that the same is true of IE5/Windows the last time I was playing with this stuff, which is why bugzilla doesn't send IE multipart content.
IE 6 / Win says > --Vhg5N7Gbj70Lgs6 > Content-Type: text/html > > <html><body>Hit 'stop' now and view source. You have 10 seconds to do > so.</body></html> > > --Vhg5N7Gbj70Lgs6 > Content-Type: text/html > > <html><body>It's too late now...</body></html> > > --Vhg5N7Gbj70Lgs6-- > Looks like you're right. IE 5.1 / Mac doesn't do it properly either. It first displays the "you have 10 seconds..." page, as does view source. But nothing happens after 10 seconds; it doesn't load the other parts.
My answer to the question "What should view-source show on a multipart page"? is "All the data as it came from the server raw". This is what is currently saved to the file when you use view source. The Mozilla web-sniffer displays everything. http://webtools.mozilla.org/web-sniffer/view.cgi?url=http%3A%2F%2Fwww.zbarsky.or g%3A8000%2Fcgi-bin%2FtestMultipartData3.pl The Mozilla browser should do the same. n.b. The web-sniffer displays the http headers, I wish the browser made it easy to display the headers (I know it can be done with about:cache-entry). View source in IE 5.01 SP2 on Windows NT displays --Vhg5N7Gbj70Lgs6 Content-Type: text/html <html><body>Hit 'stop' now and view source. You have 10 seconds to do so.</body></html> --Vhg5N7Gbj70Lgs6 Content-Type: text/html <html><body>It's too late now...</body></html> --Vhg5N7Gbj70Lgs6-- So IE gets the view source right but renders incorrectly. It shows the page as --Vhg5N7Gbj70Lgs6 Content-Type: text/html Hit 'stop' now and view source. You have 10 seconds to do so. --Vhg5N7Gbj70Lgs6 Content-Type: text/html It's too late now... --Vhg5N7Gbj70Lgs6--
I'm not convinced that "All the data as it came from the server raw" is the right answer. For normal HTML pages, "View Source" doesn't show "all the data raw"; it shows the HTML source of the currently displayed document (not the HTTP headers that preceded it, and I don't think it shows the source encoded or compressed if transfer encoding or compression was used). What most users would likely expect to see when they choose "View Source" is the HTML source of the page that is currently displayed. If a multipart mixed-replace sequence of documents was used, then they'd expect to see the source of whatever document in the sequence is currently being shown... in a Mozilla bug list, it would be the final bug list page, not the intermediate page, unless you press "View Source" very quickly before the intermediate page has given way to the final one. Most of the time that there's a conflict between what "techies" and "geeks" want/expect a function to do and what "nontechies" and "newbies" do (a conflict that's come up many times in the development of Mozilla), I side with the techies, wanting Mozilla to be the premier "geek browser" instead of being dumbed down to the masses in imitation of Microsoft (or AOL, for that matter, despite the fact that AOL kinda sorta owns Mozilla). Or at least, if Mozilla's final release version must default to doing stuff in "dumbed-down" ways to catch on with the general public, at least provide configuration options to make it more "geek-friendly". However, in this instance, despite my geekiness, I would expect view source to view the source of the currently viewed HTML document, as I don't even know as an end user whether this document was the end result of a multipart MIME document or of a "meta-refresh" or server redirect or JavaScript redirect or some other technique that would completely replace the original page, leaving no trace of it in the View Source. If I try to view or save or print the current document, what I mean is the document that is on screen now. Thus, I'd want the normal View Source function simply to give me the final document's source... if advanced features are provided to give access to earlier documents in the MIME multipart stack or to the raw data stream showing all parts, that's great, but that's an optional extra. (The "Page Info" function ought to give information both about the current [final] document and about the MIME combination of which it's a part.)
#34 I agree. When I'm seeing a page, and go to "View Source", I expect to see the source of what's currently displayed, no matter how it got there (through POST, through redirects, through multipart, etc.).
Quite a few dupes!. Pushing for 1.1 beta just because of the number of duplicates.
Target Milestone: mozilla1.0.1 → mozilla1.1beta
*** Bug 154409 has been marked as a duplicate of this bug. ***
*** Bug 155662 has been marked as a duplicate of this bug. ***
[was 1.1beta]
Target Milestone: mozilla1.1beta → Future
nominating...this affects embedded apps like chimera.
Blocks: 127253
Keywords: nsbeta1
I am not sure if the URL given in the bug is appropriate any more. I can not see this problem since the latest upgrade of Bugzilla. I could not test the URLs given in the comments, because none of them could be reached. If anybody has a URL to test this bug in the current builds, please change the URL field of this bug. 2002111208 trunk for MacOS9.x.
The url in the url field works just fine to show the problem. We now "show the source", but we in fact show the entire multipart document (all parts, including the separators) and we do no syntax highlighting.
Not seeing this bug on 1.2.1. Just HTML, fully syntax highlighted.
I wonder how you managed that, since it's quite broken in every single nightly from then to now... Perhaps you're spoofing the IE UA string so bugzilla sends you different content (since IE can't handle multipart/x-mixed-replaced content at all).
Yes, that's it exactly. I didn't realize that would have an effect.
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
*** Bug 205875 has been marked as a duplicate of this bug. ***
*** Bug 213146 has been marked as a duplicate of this bug. ***
*** Bug 222441 has been marked as a duplicate of this bug. ***
Original testcase worksforme with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 (1.7 RC2). Resolving.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
This is still a problem. There have been no changes in the code that could have fixed it. Reopening. Note comment 44, just in case.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
You definitely know better than me. But I tested it with clean program folder and new profile. No ua spoofing, no extensions. Firefox is wfm too. Is it possible to be a Linux-only issue now?
Blocks: 245276
By wfm do you mean you get HTML source or the raw multipart text? See comment 42. And no, this is XP. If there are platform differences, they are in the server-side sniffing (and should be fixed).
*** Bug 245276 has been marked as a duplicate of this bug. ***
You are right, sorry for the unecessary spam. My resolution was based on what I could recall from the first appearance of this bug (thn a blank page and a save prompt). I should have read some later comments more carefully.
Assignee: harishd → nobody
Status: REOPENED → NEW
QA Contact: moied → parser
Summary: View Source tries to DL Bugzilla buglist as multipart/x-mixed-replace → View Source shows the entire multipart response on a Bugzilla buglist (was: tries to DL Bugzilla buglist as multipart/x-mixed-replace)
This is really Networking rather than Parser. However, as long as we do support multipart/x-mixed-replace, it's semi-useful to see it all and, OTOH, it's not worthwhile to spend time on polishing multipart/x-mixed-replace support.
Status: NEW → RESOLVED
Closed: 20 years ago → 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: