thisrandomstring is not a random string

VERIFIED FIXED in Bugzilla 2.18



17 years ago
6 years ago


(Reporter: BenB, Assigned: endico)


Bugzilla 2.18




17 years ago
Bugzilla sends for query results:

Content-Type: text/html

<!-- -->

    <title>Bugzilla is pondering your query</title>
    <h1 style="margin-top: 20%; text-align: center;">Please stand by ...</h1>

Content-Type: text/html
Set-Cookie: LASTORDER=bugs.bug_id ; path=/; expires=Sun, 30-Jun-2029 00:00:00 GMT

"thisrandomstring" is *not* a random string.

Comment 1

17 years ago
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.

Comment 4

17 years ago
...or to generate a random string :)
This wound be fixed by using to handle this sort of stuff.

Comment 6

17 years ago
Note that I filed this bug more as curiosity. It is an extreme egde case.
Priority: -- → P5
Target Milestone: --- → Future

Comment 7

16 years ago
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.

Comment 8

16 years ago
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)

Comment 10

16 years ago
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 now, and it generates a unique
string. :)
Last Resolved: 15 years ago
Resolution: --- → FIXED
Target Milestone: Future → Bugzilla 2.18
Well, doesn't use a random string, but its not really our bug any more -
feel free to bug upstream.

Comment 13

15 years ago
verified, assuming the above is currect.

> feel free to bug upstream

ah, no. This was meant more as amusement.
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.