80045 - Query Page fails when email is non-existant and the matching is exact..

Status: RESOLVED FIXED

Description

[arni]

Overview Description: In Bugzilla's (2.12) query page when an entry is made in 
the text box called Email for a  user that does not exist and the matching is 
made as "exact" bugzilla konks.

Steps to Reproduce: Go to the Query page, enter an invalid user/email 
(like "hellothere") for the "Email" text box and then choose the matching pull-
dowb option as "exact".

Actual Result: Should maybe come back with a clean error saying no such user.

Expected Result: Get the Internal server error. I can send the apache logs also 
if needed.

Additional Information: I can look into this and see if I can get a patch out.

Comment 1

[Jacob Steenhagen]

That's interesting... when I ran the query in the URL bae in mozilla, I got 
the "Bugzilla is pondering your query" message w/some text below it that 
said "lkjhkjfhdfkhdsk" wasn't a valid user name... when I ran it in IE, I got a 
500 server error.

Comment 2

[Jacob Steenhagen]

Created attachment 33893 [details] [diff] [review]
print a newline before the error message in DBNameToIdAndCheck

Comment 3

[Jacob Steenhagen]

What's happening:
  Bugzilla does a check to see if it can output the "Bugzilla is pondering your
  Query" message (which only works w/Mozilla and Netscape).  If it can, it does
  If it can't, it spits out an incomplete header (so it can push more info later
  if it needs to).  Somewhere after doing that, it checks to see if the "exact"
  e-mail address matches one in the database, if it doen't the scripts errors
  out and exists (telling the user that the "exact" e-mail address isn't in the
  database).  The problem is that the error routine expects that the header has
  already been completely outputted (the blank line has already happened).

How this patch fix it:
  Before spitting out the error (and only if the error is gonna be spit out) it
  sends a blank line.  This will complete the header and makes everyone happy.
  This blank line won't have any adverse effects elsewhere because it'll only
  show up in the HTML source, not on the page itself.

While this isn't a security issue, per se, 500 errors are something to avoid and
the fix is simple, so I'm marking it 2.14.

Comment 4

[Dave Miller [:justdave] ([e-mail])]

r= justdave

Checked in.

Comment 5

[Dave Miller [:justdave] ([e-mail])]

Moving to Bugzilla product

Comment 6

[Jacob Steenhagen]

I'm not sure what info could be needed on a 17 year old bug report that had a one line fix...