Closed Bug 807674 Opened 12 years ago Closed 12 years ago

[socorro-crashstats] 500 Internal Server Error in signature_summary


(Socorro :: Webapp, task)

Not set


(Not tracked)



(Reporter: stephend, Unassigned)




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


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.
(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.
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?
(In reply to Robert Helmer [:rhelmer] from comment #7)
> 1) we definitely have <> working e.g.
> 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.
WFM too; someone can close it and I'll verify.  Thanks!
Closed: 12 years ago
Resolution: --- → WORKSFORME
Verified WFM
You need to log in before you can comment on or make changes to this bug.