Bugzilla sends for query results: --thisrandomstring Content-Type: text/html <!-- email@example.com --> <html> <head> <title>Bugzilla is pondering your query</title> </head> <body> <h1 style="margin-top: 20%; text-align: center;">Please stand by ...</h1> </body> </html> --thisrandomstring Content-Type: text/html Set-Cookie: LASTORDER=bugs.bug_id ; path=/; expires=Sun, 30-Jun-2029 00:00:00 GMT [...] </html> --thisrandomstring-- "thisrandomstring" is *not* a random string.
I've wondered the same, but I don't think it's supposed to be really random, but rather "notaspecificstring". Myk, can you confirm this?
Severity: normal → trivial
That's correct. It doesn't matter what the string is, just that it doesn't appear in the content anywhere (since it separates each piece of content from the next. Of course, this does mean that if someone prepends two dashes to the subject of this bug it will mess up bug lists with this bug in them, so perhaps it is a bug (now that you mention it).
It doesn't matter what string you choose, someone can construct a bug with that in the summary. The only reliable way to avoid this is to work out a string for each bug report that isn't in it.
...or to generate a random string :)
This wound be fixed by using CGI.pm to handle this sort of stuff.
Note that I filed this bug more as curiosity. It is an extreme egde case.
This bug causes Apple's Safari (build 60, latest at time of writing) to download results of queries, rather than display them, as the browser doesn't see the content-type:text/html line. So in my mind this is now quite a serious bug.
Thinking through this, it seems to me the problem is as follows.... When Bugzilla displays: Please stand by ... Bugzilla relies on non-standard browser functionality, whereby the content of the first <html> element is displayed, replace by the content of the second <html> element when it's been received. Of course the second instance is only streamed out when the query is complete. So this fudge is merely an overly simple way of asking people to be patient. As its not standard, it should go, right? Perhaps by moving the Content-type: text/html line to be the first line of the file whatever happens, or by changing the cgi. Can anyone verify this?
This is not the bug that causes Safari to choke. Bugzilla differentiates between browsers that can and cannot do server push and only uses this technique for supporting browsers. Safari apparently looks like one. Please file a new bug for this problem and cite the following Safari user-agent string: "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/60 (like Gecko) Safari/60"
RE Comment 7 - 9: The problem is that Apple doesn't use the standard flag "Compatible" to specify that it's not really "Mozilla/5.0" This has been reported and fixed in the tip, but I don't believe that bmo has picked it up yet (see bug 188712).
This was fixed a while back. We use CGI.pm now, and it generates a unique string. :)
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Target Milestone: Future → Bugzilla 2.18
Well, CGI.pm doesn't use a random string, but its not really our bug any more - feel free to bug upstream.
verified, assuming the above is currect. > feel free to bug upstream ah, no. This was meant more as amusement.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.