807674 - [socorro-crashstats] 500 Internal Server Error in signature_summary

Status: VERIFIED WORKSFORME

(Socorro :: Webapp, task)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

This might be a duplicate, but wanted to file just in case:

http://crash-stats-new-dev.allizom.org/signature_summary/json_data?range_value=7&range_unit=days&signature=xul.dll%400x97ac34+|+xul.dll%400x8459aa+|+xul.dll%400x844f64+|+xul.dll%400x920f0b+|+xul.dll%400x921f00+|+xul.dll%400x92120e+|+xul.dll%400x9212d8+|+xul.dll%400x923f74%00%27%22--%3E%3C%2Fstyle%3E%3C%2Fscript%3E%3Cscript%3Enetsparker%280x000C98%29%3C%2Fscript%3E&version=B2G%3A19.0a1&date=2012-10-31 throws a 500.

Comment 1

[Schalk Neethling [:espressive]]

So, what is causing this is the signature and more specifically the -- in the signature, if you remove those, the request succeeds and an empty response is returned.

So, this seems to be to be part of the larger issues of signature encoding but, with that said, should we not simple mark signatures that contains <script> tags as invalid and return an empty result and/or a message back to the user or, is it common to for these to occur in signature? My gut feeling is, it is not.

Comment 2

[Robert Kaiser]

We need to make things work with all kinds of stuff in signatures. I don't see signatures being restricted to certain characters or formats in the future, we probably will open up even more signature formats and therefore "weird" things appearing in them. We might put up abort messages as signatures, and e.g. "<script> not allowed in this context" might very well be a perfectly good signature then. We need to harden our mechanisms to allow such signatures, not return unexpected stuff, no matter if that's errors or emptiness.

Comment 3

[Schalk Neethling [:espressive]]

Hey KaiRo,

I completely agree. If it is a case where <script type tags might occur in signatures, then we will have to handle those. In actual fact, in this case it does not seem like the <script> tags causing the problem but, those two little --

Comment 4

[Schalk Neethling [:espressive]]

Actually looking at this again, the problem relate to the < and > characters as running the bit of the URL from the -- through a url encoder produces the following:

--%3E%3C%252Fstyle%3E%3C%252Fscript%3E%3Cscript%3Enetsparker(0x000C98)%3C%252Fscript%3E

replacing what is in the URL above with this, fixes the 500 error, so it seems we are simply not encoding < and > signs in signatures.

Comment 5

[Robert Kaiser]

(In reply to Schalk Neethling [:espressive] from comment #4)
> replacing what is in the URL above with this, fixes the 500 error, so it
> seems we are simply not encoding < and > signs in signatures.

Good find. Also, we definitely have signatures right now that contain < and > characters, so we should really fix this.

Comment 6

[Schalk Neethling [:espressive]]

Adding Rob to the conversation here, I know he as well as peterbe did a bunch of work on signatures. :rhelmer, could it be this simply slipped through the cracks or am I misdiagnosing the problem?

Comment 7

[Robert Helmer [:rhelmer]]

1) we definitely have <> working e.g. http://crash-stats-new-dev.allizom.org/report/list?range_value=7&range_unit=days&date=2012-11-04&signature=mozilla%3A%3Agfx%3A%3ABaseRect%3Cint%2C+nsIntRect%2C+nsIntPoint%2C+nsIntSize%2C+nsIntMargin%3E%3A%3AUnion%28nsIntRect+const%26%29&version=Firefox%3A19.0a1 (see the signature summary tab)

2) I don't see any problem with the URL in comment 0, could this have been fixed in the meantime?

Comment 8

[Schalk Neethling [:espressive]]

(In reply to Robert Helmer [:rhelmer] from comment #7)
> 1) we definitely have <> working e.g.
> http://crash-stats-new-dev.allizom.org/report/
> list?range_value=7&range_unit=days&date=2012-11-
> 04&signature=mozilla%3A%3Agfx%3A%3ABaseRect%3Cint%2C+nsIntRect%2C+nsIntPoint%
> 2C+nsIntSize%2C+nsIntMargin%3E%3A%3AUnion%28nsIntRect+const%26%29&version=Fir
> efox%3A19.0a1 (see the signature summary tab)
> 
> 2) I don't see any problem with the URL in comment 0, could this have been
> fixed in the meantime?

Works for me now as well, definitely was not earlier.

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

WFM too; someone can close it and I'll verify.  Thanks!

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified WFM