Closed Bug 158166 Opened 22 years ago Closed 21 years ago

thisrandomstring is not a random string

Categories

(Bugzilla :: Query/Bug List, defect, P5)

x86
Linux
defect

Tracking

()

VERIFIED FIXED
Bugzilla 2.18

People

(Reporter: BenB, Assigned: endico)

Details

Bugzilla sends for query results:

--thisrandomstring
Content-Type: text/html

<!-- 1.0@bugzilla.org -->



  
<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.
Priority: -- → P5
Target Milestone: --- → Future
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
Closed: 21 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
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.