user wrote:The payloads won't be huge because we're talking about _down_loads, not _up_loads. The biggest payload I've seen was on some filehosting: about 2 KB, 10+ hidden form fields. But that's an "extreme" case, usually it'll be even less - just a download/request/transaction ID and/or a disposable request token to prevent request replay. For instance, Grooveshark's payload is about 100 bytes.
That's what I guessed too, but still handling POST-triggered download is required as a built-in feature of Firefox's download manager, and in the general case you can't rely on website to play nice or use common sense (a huge upload which gets serialized in memory as a JSON string could be used as a DOS attack).
user wrote: I think the one in the beginning of observe() can be safely dropped because if I'm not missing anything, observe() is called either by the browser (who, I think, won't call it for an incomplete/interrupted response) or by MediaSniffer::onStateChange
I choose to drop the one in onStateChange() instead, because as far as I can see it just calls observe() which is already guarded.
As for the observers not being called on non-success codes, I'd prefer to err on the safe side.
user wrote:And before you merge: there's another comment (DMS.js, line 2566) that AMO auditors probably won't like. Although I don't understand why do you care about their likes. I thought their job is auditing the code, not approving the comments.
I already noticed and removed it, thanks. As much as I share your feelings about breaking stuff by fixing what's not broken, I'm part of that community too, and generally prefer to discuss such issues politely (like in "open a bug report", as I did) rather than creating hard feelings which don't get things fixed and alienate collaborative attitudes
