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

Status: RESOLVED FIXED

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

Description

[Kev Needham [:kev]]

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?

Comment 1

[Shyam Mani [:fox2mike]]

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?

Comment 2

[Kev Needham [:kev]]

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.

Comment 3

[Kev Needham [:kev]]

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.

Comment 4

[(not currently active) Ted Mielczarek]

Microsoft's tools are very bad about consistency with case sensitivity. :-/

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

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 ?

Comment 6

[Kev Needham [:kev]]

Can we get this looked at, please?

Comment 7

[Shyam Mani [:fox2mike]]

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

Comment 8

[Nick Thomas [:nthomas] (UTC+12)]

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 ?

Comment 9

[Shyam Mani [:fox2mike]]

No idea whatsoever :( which one of the rules would you like me to apply?

Comment 10

[Nick Thomas [:nthomas] (UTC+12)]

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).

Comment 11

[Shyam Mani [:fox2mike]]

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 :)

Comment 12

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 13

[Shyam Mani [:fox2mike]]

Thanks! All done and seems to work now.

Comment 14

[Kev Needham [:kev]]

Thanks folks, really appreciate you getting on this and working it through.

Comment 15

[(not currently active) Ted Mielczarek]

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.