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)
Core
DOM: HTML Parser
Tracking
()
RESOLVED
WONTFIX
Future
People
(Reporter: tarahim, Unassigned)
References
()
Details
Attachments
(2 files)
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.
Comment 1•24 years ago
|
||
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
Comment 3•24 years ago
|
||
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
Comment 4•24 years ago
|
||
Comment 10•23 years ago
|
||
I see this also when trying to view source on a bugzilla query response
Comment 11•23 years ago
|
||
*** Bug 98853 has been marked as a duplicate of this bug. ***
Comment 12•23 years ago
|
||
*** Bug 100436 has been marked as a duplicate of this bug. ***
Comment 13•23 years ago
|
||
*** Bug 103152 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
*** Bug 104574 has been marked as a duplicate of this bug. ***
Comment 15•23 years ago
|
||
*** Bug 104736 has been marked as a duplicate of this bug. ***
Comment 16•23 years ago
|
||
*** Bug 105635 has been marked as a duplicate of this bug. ***
Comment 17•23 years ago
|
||
*** Bug 111814 has been marked as a duplicate of this bug. ***
Comment 18•23 years ago
|
||
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
Comment 19•23 years ago
|
||
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!
Comment 20•23 years ago
|
||
This seem to have a lot of duplicates. Moving to 0.9.9.
Comment 21•23 years ago
|
||
*** Bug 134270 has been marked as a duplicate of this bug. ***
Comment 22•23 years ago
|
||
*** Bug 134956 has been marked as a duplicate of this bug. ***
Comment 23•23 years ago
|
||
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.
Comment 24•23 years ago
|
||
#23
How do other browsers handle this? How did earlier Netscape versions?
Comment 25•23 years ago
|
||
> 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.
Comment 26•23 years ago
|
||
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?
Comment 27•23 years ago
|
||
> 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.
Comment 28•23 years ago
|
||
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.
Comment 29•23 years ago
|
||
Comment 30•23 years ago
|
||
#28, #29
You're absolutely right. IE isn't getting any multipart version, at least not IE6.
Comment 31•23 years ago
|
||
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.
Comment 32•23 years ago
|
||
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.
Comment 33•23 years ago
|
||
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--
Comment 34•23 years ago
|
||
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.)
Comment 35•23 years ago
|
||
#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.).
Comment 36•22 years ago
|
||
Quite a few dupes!. Pushing for 1.1 beta just because of the number of duplicates.
Target Milestone: mozilla1.0.1 → mozilla1.1beta
Comment 37•22 years ago
|
||
*** Bug 154409 has been marked as a duplicate of this bug. ***
Comment 38•22 years ago
|
||
*** Bug 155662 has been marked as a duplicate of this bug. ***
[was 1.1beta]
Target Milestone: mozilla1.1beta → Future
Comment 40•22 years ago
|
||
nominating...this affects embedded apps like chimera.
Reporter | ||
Comment 41•22 years ago
|
||
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.
Comment 42•22 years ago
|
||
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.
Comment 43•22 years ago
|
||
Not seeing this bug on 1.2.1. Just HTML, fully syntax highlighted.
Comment 44•22 years ago
|
||
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).
Comment 45•22 years ago
|
||
Yes, that's it exactly. I didn't realize that would have an effect.
Comment 47•22 years ago
|
||
*** Bug 205875 has been marked as a duplicate of this bug. ***
Comment 48•21 years ago
|
||
*** Bug 213146 has been marked as a duplicate of this bug. ***
Comment 49•21 years ago
|
||
*** Bug 222441 has been marked as a duplicate of this bug. ***
Comment 50•21 years ago
|
||
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: 21 years ago
Resolution: --- → WORKSFORME
Comment 51•21 years ago
|
||
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 → ---
Comment 52•21 years ago
|
||
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?
Comment 53•21 years ago
|
||
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).
Comment 54•21 years ago
|
||
*** Bug 245276 has been marked as a duplicate of this bug. ***
Comment 55•21 years ago
|
||
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.
Updated•17 years ago
|
Assignee: harishd → nobody
Status: REOPENED → NEW
QA Contact: moied → parser
Updated•8 years ago
|
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: 21 years ago → 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•