Closed Bug 660932 Opened 9 years ago Closed 9 years ago

Verify symbols.mozilla.org still supports case-insensitive queries

Categories

(mozilla.org Graveyard :: Server Operations, task, critical)

x86
Windows 7
task
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kev, Assigned: fox2mike)

Details

Per bug 414852, MS development tools use case-insensitive queries to the symbol server. One of our partners have reported that symbols can no longer be retrieved, and that they suspect that it's due to the same issues involving MS's case handling. Could we verify that the symbols server will still serve up symbols properly to queries made through MS's Symbol Proxy, and that the onfig outlined in 414852 is still in place?
Kev,

This is working fine, for the very same example Nick provided in Bug 414852 :

trinity:~ shyam$ curl -I -L http://symbols.mozilla.org/firefox/xpt_link.pdb/470ac3db2/xpt_link.sym
HTTP/1.1 200 OK
Date: Wed, 01 Jun 2011 05:05:49 GMT
Server: Apache
X-Backend-Server: pm-web01
Last-Modified: Thu, 25 Oct 2007 14:33:35 GMT
ETag: "ec18f9-4baf-1e7d8dc0"
Accept-Ranges: bytes
Content-Length: 19375
Content-Type: text/plain; charset=UTF-8

trinity:~ shyam$ curl -I -L http://symbols.mozilla.org/firefox/xpt_link.pdb/470AC3DB2/xpt_link.sym
HTTP/1.1 200 OK
Date: Wed, 01 Jun 2011 05:06:04 GMT
Server: Apache
X-Backend-Server: pm-web01
Last-Modified: Thu, 25 Oct 2007 14:33:35 GMT
ETag: "ec18f9-4baf-1e7d8dc0"
Accept-Ranges: bytes
Content-Length: 19375
Content-Type: text/plain; charset=UTF-8

What is broken exactly? Can you give us an example?
Hum. I'll get more details, they were saying they were getting 404s. I'll re-verify, and should have figured out how to test on my own, so apologies for the extra work. Checking into it further.
Assignee: server-ops → shyam
Sorry for the delay, just got steps to replicate:

1)	Open a web browser and use http://symbols.mozilla.org/firefox/firefox.pdb/F123918588AF463C89AD103F1C19235C2/firefox.pd_ to simulate a symbol request.
2)	Everything is happy and you are able to retrieve the symbol file without issue.
3)	Now change one of the GUID characters to lower case as we did with the "f" in this link http://symbols.mozilla.org/firefox/firefox.pdb/f123918588AF463C89AD103F1C19235C2/firefox.pd_ and make the symbol request.
4)	The symbol file is not retrieved.

This is the issue they're hitting.
Microsoft's tools are very bad about consistency with case sensitivity. :-/
So the differences between comment #1 and #3 are longer UIDs and requesting a pd_ instead of a sym. The rewrites at bug 414852 comment #1 don't appear to care about either at face value. It's not the underscore causing the problem, because the same happens with the sym's:

http://symbols.mozilla.org/firefox/firefox.pdb/F123918588AF463C89AD103F1C19235C2/firefox.sym --> 200 response
http://symbols.mozilla.org/firefox/firefox.pdb/f123918588AF463C89AD103F1C19235C2/firefox.sym --> 404 response 

Is bug 414852 comment #1 what's in use on the server ?
Can we get this looked at, please?
Severity: normal → critical
Nick,

RewriteMap toupper int:toupper
    RewriteRule ^/firefox/(.+?)/([\d\w]{9})/(.*) /firefox/$1/${toupper:$2}/$3

That's what's on the box. 

The entire re-direct block is :

    RewriteMap toupper int:toupper
    RewriteRule ^/firefox/(.+?)/([\d\w]{9})/(.*) /firefox/$1/${toupper:$2}/$3
    RewriteRule ^/firefox/(.*)$ /symbols_ffx/$1 [L]
    RewriteRule ^/seamonkey/(.*)$ /symbols_sea/$1 [L]
    RewriteRule ^/sunbird/(.*)$ /symbols_sbrd/$1 [L]
    RewriteRule ^/thunderbird/(.*)$ /symbols_tbrd/$1 [L]
    RewriteRule ^/xulrunner/(.*)$ /symbols_xr/$1 [L]
    RewriteRule ^/fennec/(.*)$ /symbols_mob/$1 [L]
    RewriteRule ^/$ https://developer.mozilla.org/en/Using_the_Mozilla_symbol_server
Ok, it's clear the blame is the {9} in [\d\w]{9} then. We could change that to *, like this
  RewriteRule ^/firefox/(.+?)/([\d\w]*)/(.*) /firefox/$1/${toupper:$2}/$3
or allow 9 to 33 chars
  RewriteRule ^/firefox/(.+?)/([\d\w]{9,33})/(.*) /firefox/$1/${toupper:$2}/$3
Or even
  RewriteRule ^/firefox/(.+?)/([\da-zA-Z]*)/(.*) /firefox/$1/${toupper:$2}/$3
to exclude punctuation matches from \w.

Since the rule has changed since this was first set up, is there any history on why that happened ? Security review maybe ?
No idea whatsoever :( which one of the rules would you like me to apply?
No change history in puppet that might give you a clue ? 

AFAICT, they're all equivalent, so whichever one looks best to you (as a person who has written more rewrite rules before breakfast than I ever have).
I suck at mod_rewrite and as a person who's had a watery dinner, you should decide and I'll help get it live :)
Alright then. Please use this one
  RewriteRule ^/firefox/(.+?)/([a-fA-F\d]*)/(.*) /firefox/$1/${toupper:$2}/$3

Hopefully it will prevent MS changes breaking us again.
Thanks! All done and seems to work now.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Thanks folks, really appreciate you getting on this and working it through.
FTR, I don't think this was a regression. As originally implemented, we only saw case problems with the shorter identifiers, and this new problem was with the longer identifiers when called via a symbol proxy, which is likely the new part that was causing the issue.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.