Problem with HTTP GET in notification script

Hi all,

Previous posts have spoken of using a script with HTTP GET. This has worked really well (infact, writing over 40,000 records to the database), but since changing to a new web server no longer works. The line is:

HTTPGetAsync('http://external.stationwebsite.com/nowplaying/log.php?title=' + Item.GetTitle + '&artist=' + Item.GetArtist + '&source=studio1' );

When the script runs in mAirList, the data isn’t recorded and the website isn’t accessible for around ten minutes to any traffic from the IP which mAirList is on.

However, when I sit in Chrome or Firefox on the same PC and put that URL together in the browser, I can see the record being written instantly and there’s no connection problems.

I know it sounds very odd, and I’ve now tried on a variety of PCs and different DSL connections - I just wondered if anyone had any thoughts, especially as the same string works in a browser fine?

How many characters altogether would be in the string being used as a parameter to HTTPGetAsync, after everything has been substituted?

BFN
CAD

Hi Cad,

Thank you for the quick reply. I’ve had a look and I’m not absolutely sure which characters to count, if I’m completely honest. I’ve conducted it with Wireshark open and picked out the following lines:

Browser

(This is manually entered into the address bar)

No. Time Source Destination Protocol Info
54 6.329535 192.168.0.2 xx.xx.xx.xx HTTP GET /nowplaying/log.php?title=Surrender&artist=Cheap%20Trick&source=chrome HTTP/1.1

No. Time Source Destination Protocol Info
65 6.557172 xx.xx.xx.xx 192.168.0.2 HTTP HTTP/1.1 200 OK

mAirList

(This is mAirList’s with the same title and artist from the played item)

No. Time Source Destination Protocol Info
485 40.263045 192.168.0.2 xx.xx.xx.xx HTTP GET /nowplaying/log.php?title=Surrender&artist=Cheap%20Trick&source=studio1 HTTP/1.1

No. Time Source Destination Protocol Info
487 40.501505 xx.xx.xx.xx 192.168.0.2 HTTP HTTP/1.1 403 Forbidden (text/html)

Ok - eventually found something in the Apache logs.

Access denied with code 403 (phase 2). Pattern match "indy library" at REQUEST_HEADERS:User-Agent.

I guess it’s a hosting company issue with their security?

I’m no expert on all this, but I’d say that it’s &source=studio1 (as opposed to the browser name: chrome in your case) that the server is moaning about.

‘User-agent’ frequently = browser type/name. :wink:

Send the error message to your ISP’s white-coated boffins and see what they advise.

BFN
CAD

I think the problem is actually the use agent (browser name sent in HTTP request). mAirList uses the Indy library. Your ISP is apparently blocking anything that is not a real browser (Internet Explorer or Mozilla).

Yep - it was down to the User-agent.

Turns out the hosting co. uses Atomic Security Linux and as the User String wasn’t recognised, it was triggering a rule.

After speaking to support they were able to add an exclusion for the domain and now everything works great.

Thank you again Cad and Torben for your help.