GNOME Bugzilla – Bug 634335
Failed HEAD aborts gvfs-open for HTTP URL
Last modified: 2011-05-17 10:14:21 UTC
The test case is access to http://www.imdb.com using the default browser via the JDIC (Java Desktop Integration Components) Browser API. When gvfs-open receives control programmatically from a program attempting to launch the default browser for an HTTP URL, it first sends a HEAD request for that URL. The HEAD may fail for a number of reasons. In my case, IMDB is configured to reject requests with a "User-Agent:" header which doesn't match the set of well-known browser values; this is common practice for sites that don't want to be accessed programmatically. Access by the default browser (Mozilla) would work just fine, for HEAD or GET, but the gvfs HEAD fails because it reports the User-Agent as "gvfs/1.6.5", which is not acceptable to IMDB. . If the HEAD does fail, gvfs aborts the request. I can't find a way to configure the User-Agent that gvfs uses. But even if there is such a way, it shouldn't be necessary. If the default browser is to be invoked with a URL, gvfs ought not be trying to use the URL first. If it absolutely has to for some reason, then it ought to silently accept the HEAD failure and pass control to the default browser, which can do its own HEAD if it wants to. As it is, the only error message goes to the gvfs stdout/stderr which isn't seen if the call is made from a GUI application. Thus, the user has no idea what went wrong, except that no browser window opens. This was working fine a few months ago. To reproduce easily from the copmmand line: [ftg@ftgme2 release]$ gvfs-open http://www.imdb.com gvfs-open: http://www.imdb.com: error opening location: HTTP Error: Method Not Allowed
Very nice analysis of the problem.This bug is actually a dup of 547020. And related to bug 601776. *** This bug has been marked as a duplicate of bug 547020 ***
Hmmmm. Long before I filed this, I checked that a java-initiated HTTP GET to IMDB from an EJB failed with "Forbidden" unless I set User-Agent to something "vanilla". When I came across this, I assumed it was the same thing. However, I've just tried a specific test with a GET using a User-Agent of "gvfs/1.6.5" against IMDB, and it worked. My original assumption was that most servers obey the HTTP spec, which requires that they return the same response for HEAD as GET, minus the response body. Knowing that IMDB was discriminating against GETs based on the UA, it made sense that they were doing it for HEADs as well. I don't have a simple way to force a HEAD to IMDB with a bogus UA. It may be that IMDB responded to this GNOME behavior by adding "gvfs/1.6.5" to their whitelist. But I would encourage you to check in the other failing cases whether the same GET with the identical UA fails as well. I'd find it really unusual that an HTTP server would screw up such a basic violation of the spec, or that multiple sites would have targeted HEAD but not GET.
FWIW, I'm getting different site design for various user agents (Firefox vs. Midori). Apparently IMDB is doing some magic, wouldn't be surprised of other issues.