InformAction Forums

hi,

musicbrainz.org has changed their cover-art uploading routine (link to the a thread a bout the old one http://forums.informaction.com/viewtopi ... usicbrainz) and now it looks like abe is causing problems for me.

when i have abe enabled i get an error after my first attempt to upload a cover and after i try it again everything works. when i disable abe everything works fine.

after doing some research i found this ticket (http://tickets.musicbrainz.org/browse/MBS-4376) where they mention that they use CORS (Cross-origin resource sharing). is it possible that this is the part which causes problems with abe and how can i solve those problems? was fooling around with some abe rules but i'm not able to make it work.

thanks for any help with this

Could you copy and paste here any error message you get from ABE, either in the yellow notification bar or in your Error Console (Ctrl+Shift+J)?

i just get warnings for some css declarations. no errors either in the error console nor do i get one in the yellow bar.
but if i deactivate abe (or noscript) the upload works.

i'm not sure if it really is a bug of abe rather then some different behaviour when it is activated which causes the error.
i did some sniffing with wireshark and along the line it did some with fiddler too. and the funny thing is, that while fiddler was running/sniffing too, it caused the upload to work.

in wireshark and fiddler i can see that my client gets a json-file with some info (including a signature which is needed for the upload).
after that there appears to be different behaviour of my client:
when abe/noscript is on and fiddler deactivatet i can see a GET of my client which the server responses with a 404
when abe/noscript is off or fiddler activated the clients sends an OPTION instead of a GET. other then that the packages look pretty much the same. but the server responds with an 200 instead of the 404.

when i get the error (with abe/noscript activated) in my browser i can start that upload again and at that time it works. the browser sends a request for that json-file again. the server responds with that json-file. and then the browser sends that OPTION request which now gets a 200 as a response.

i'm quite puzzeled about where the problem is really located.

Is there anything in the Messages tab of the Error Console? That's where ABE normally logs its activity (since an ABE rule firing is just an event, not an error).

nope, nothing

i found a simple demo (from here: http://arunranga.com/examples/access-control/) where you can see the same behavior: http://arunranga.com/examples/access-co ... ation.html
if you whitelist those two sites (arunranga.com & aruner.net) and click the button you get an error on the first attempt and after that the demo works.
and when you sniff the traffic you can see that the browser is sending a GET request instead of the necessary OPTIONS request. at the second attempt he sends the OPTIONS request and it works.

i don't have lots of knowledge in this html5 stuff, but has this something to do with what's written in this article http://www.nczonline.net/blog/2010/05/2 ... e-sharing/ under "Preflighted requests"?

also you'll notice that at the first attempt one of the sites will not show up in the permissions menu (how could noscript even know. so i guess that's expected).

has anyone tried the second link i provided and can confirm that this is not only broken for me?

are there any news on this? tried it on different installations and the error occurred on all of them.

is this behavior of noscript intentional because of security reasons or would this be considered as a bug?
if it's a bug, is there any estimated time for this to be fixed?

i imagine that this isn't that big of a problem and isn't high priority. i also imagine that this won't be fixed instantly due to time constraints. but at least a bit of feedback would be appreciated.

I had a go at checking it out, and sometimes noticed an error message in the Error Console with no text. I haven't dug into more detail.

It would be very strange, though, for ABE to be converting an OPTIONS request into GET.

thx for giving it a go

yet, still it happens to do so. and when you disable abe it works on the first run.
but yeah, it's weird because if i have fiddler running (i think it acts as a proxy) it works with abe activated too for whatever reasons. you might be right if you say that abe or noscript aren't the sole reason this is happening, but something in abe seems to trigger it.

i'm wildly guessing though because i don't have any insights about the firefox addons api, noscript and what else could be involved in this.

can't find the official changelog for 2.6.8.2 but it seems to work now. am I right that the change from v 2.6.8.2rc2 is the fix?

v 2.6.8.2rc2
=========================================================================
x Fixed request methods different than POST being turned into GET by
internal channel redirection when the DNS entry is not cached yet

Anyways, it's fixed now and it works fine! Thank you very much!

Guest wrote: v 2.6.8.2rc2
=========================================================================
x Fixed request methods different than POST being turned into GET by
internal channel redirection when the DNS entry is not cached yet

That does indeed look like your bug.

Normally Giorgio posts something when he releases a development build to fix something. Maybe he's forgotten, or maybe he just hasn't seen this thread and he noticed & fixed it independently. Either way, I'm glad it works for you .