I would like to remind Web Service users that on 16 November we’re going to block generic User-Agent strings from accessing our web service. Earlier we said:
The User-Agent string needs to identify the application and the version of the application that is making the request; having a generic User-Agent string like “Java/1.6.0_24″ or “PHP/5.3.4″ does not allow us to properly identify the application making the requests.
IMPORTANT: 6 Months after we release NGS (Nov 16th) we’re going to start blocking common generic User-Agents strings, so please make sure that you send us a proper User-Agent header as part of your request.
You have been warned. 🙂
9 thoughts on “Web service user-agent string blocking reminder”
Are the userjs concerned by this block ? I guess current user agents might be something like
Opera/9.80 (Windows NT 5.1; U; en) Presto/2.9.168 Version/11.52(depending on the browser).
Are these allowed ?
patate12: No, it should not. The blocking will be for /ws/1 and /ws/2
Or to answer the actual question, no, we’re not planning to block browser UA strings.
I’m looking at libwebservice-musicbrainz-perl, (Query.pm:130) which sets the User-Agent header to “WebService::MusicBrainz/0.93”. There are no hooks for applications to modify the User-Agent header in this library. Will this library be at risk?
Thanks for the answers ! I’ve been unworried. 🙂
Paul: No we’re not going to block those. First we need to add support for setting user agent strings in all of our client libs. Then we’ll need to allow the generic strings like this one for at least a year before we start blocking those. I’m working on a comprehensive plan for all of this now.
Does this affect pymusicbrainz? Getting this with a script that uses 0.7.3 now:
Couldn’t fetch release: HTTP Error 400: Bad Request
Andrew: If that problem persists, its a bug and you should open a ticket for it.
The solution is to replace:
q = Query(service)
q = Query(ws=service, clientId=”gen_encoding-0.2″)
i.e. set a clientid.