ID3 Reader and ASP.NET

[KhaosVoid]

I am having difficulty implementing your js library in an IIS/ASP.NET environment. Currently, I am doing prototyping on a local instance of IIS Express and when I try to pull the ID3 tags, I get the generic HTTP 400 'Bad Request' error. The sub code returned is 0.

I have tried referencing the source files so that I could debug further (Firefox), and found that it dies on the getHead function:oHTTP.open() call in bufferedbinaryajax.js, line 129. This is when the 400 error occurs.

Could this perhaps be a web.config error of some kind that I'm missing? Or is there a discrepancy in how the ID3 library requests are interpreted between Apache (your demo site) and IIS/ASP.NET?

I've also tried this in another project of mine that uses Ajax for webmethod and WCF service calls and had experienced the same behavior.

Library looks great. I have been looking forward to implementing this for a while, as it should let me make a playlist without any kind of manifest storing the ID3 information.

Thanks.

[António Afonso]

I haven't used IIS for 10 years or so to be honest. The XHR reader makes HEAD requests to get the content-length of the file. Maybe for some reason IIS is not responding to HEAD requests?
Can you check the network tab of the browser debugger to get more info on the request sent?
The 400 means that the browser sent a malformed request to the server, or in a way the server isn't able to respond.
Any chance of checking IIS logs to know why IIS is not able to respond?

[Håvard Gulldahl]

Hey guys, I'm running into this as well, and I thought I'd share some details.

First, the HEAD request. Here's the IIS replying:

HTTP/1.1 304 Not Modified
Last-Modified: Thu, 23 Apr 2015 08:41:01 GMT
Accept-Ranges: bytes
ETag: "1bfc733aa17dd01:0"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Sat, 25 Apr 2015 22:52:40 GMT

And then comes the Range request.

GET /Cache27/mp3/20184016.mp3 HTTP/1.1
Host: madmasrv01
Connection: keep-alive
Cache-Control: max-age=0
If-Modified-Since: Sat, 1 Jan 1970 00:00:00 GMT
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36
Range: bytes=0-4095
Accept: /
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,nb;q=0.6,sv;q=0.4,da;q=0.2

Here's the reply.

HTTP/1.1 400 Bad Request
Content-Type: text/html
Last-Modified: Thu, 23 Apr 2015 08:41:01 GMT
Accept-Ranges: bytes
ETag: "1bfc733aa17dd01:0"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Sat, 25 Apr 2015 22:52:40 GMT
Content-Length: 11

Bad Request

I notice that there's no content-length in the reply to the HEAD request.

Let me know if there is anything else I can provide to help solve this issue.

Cheers.

[Håvard Gulldahl]

Seems like @TheFuzzball is onto the same thing.. https://github.com/TheFuzzball/JavaScript-ID3-Reader/commit/c0ff389d72f25e2fcb9db212932c8fd8087e80b1

Alas, I haven't been able to test their patch to see if it actually solves my problem. What do you think?

[António Afonso]

I don't think that @TheFuzzball commit fixes the issue, it just assumes 2047 bytes when no Content-Length is available... (not sure why though).
In your case you just don't get any data when making the Range request, so even if the Content-Length is being returned in the HEAD request your 400 problem would still persist.

From the response to the HEAD request it seems that IIS is accepting Range requests, so I'm not sure why it's returning a 400.
Can you try getting the file with curl to see if there's any header the library is sending that will make IIS respond in that way?

curl --head -r 0-4095 http://domain.com/Cache27/mp3/20184016.mp3

PS: NRK is awesome :-)

[Håvard Gulldahl]

Using Postman, this Range request worked just fine:

GET /Cache27/mp3/19950776.mp3 HTTP/1.1
Host: madxxx
Range: bytes=0-4096

I got a HTTP 206 Partial content and 4097 bytes of data.

Going through the headers one by one reveals that there are actual two headers in the original request that trip IIS over:

• If-Modified-Since: Sat, 1 Jan 1970 00:00:00 GMT returns 400 Bad Request
• Accept: / returns 406 Not acceptable (since there is no mime major or minor part in that query)

If you try to strip all headers from the xhr request I bet everything runs swimmingly!

[António Afonso]

The If-Modified-Since issue was actually fixed in February by @xps but I haven't created a minimized version of it yet, sorry about that.
I'm more puzzled about the Accept header since that's automatically sent by the browser, it's not set through JavaScript.
Can you try using the non minimized version of the library?

[Håvard Gulldahl]

Sorry for being daft, but where can I find the non minimized version?

[António Afonso]

I don't have a single file for it, so you just have to include all the files in the source directory.