Below is some debugging via CLI to show that the user agent HTTP header is required. Why they block requests without it is way beyond me. But they do...

Without user agent:

$ php -r 'ini_set("user_agent", ""); @file_get_contents("http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl"); print_r($http_response_header);'
Array
(
    [0] => HTTP/1.0 503 Service Unavailable
    [1] => Cache-Control: no-cache
    [2] => Connection: close
    [3] => Content-Type: text/html
    [4] => Content-Length: 310
)

With user agent:

$ php -r 'ini_set("user_agent", "."); @file_get_contents("http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl"); print_r($http_response_header);'
Array
(
    [0] => HTTP/1.1 200 OK
    [1] => Date: Thu, 23 May 2013 10:39:18 GMT
    [2] => Accept-Ranges: bytes
    [3] => Content-Length: 10201
    [4] => Last-Modified: Wed, 12 Dec 2012 19:10:13 GMT
    [5] => Server: Europa
    [6] => Connection: close
    [7] => Set-Cookie: MYSRV=server04; path=/
    [8] => Cache-control: private
)

The PHP directive which sets the HTTP user agent header (user_agent), is not set by default. With such a configuration the connection with VIES will fail. The solution for site builders is to set this PHP directive in their PHP configuration.
I think this module should do more to prevent this headache for site builders. At the very least it should be documented, but I'd prefer the SoapClient creation to include the user agent option. See: http://www.php.net/manual/en/soapclient.soapclient.php

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

a.ross’s picture

Status: Active » Needs review
FileSize
873 bytes

Something like this:

ZeiP’s picture

Status: Needs review » Reviewed & tested by the community

This indeed did the trick, but only after upgrading my PHP. As per the PHP bug concerning the user_agent option, this fix only works with PHP version >= 5.3.11: http://svn.php.net/viewvc/?view=revision&revision=323909 ; this should be somehow indicated in the documentation and during install phase requirements.

ZeiP’s picture

Component: Documentation » Code
Priority: Normal » Major

Adjusting priority and component.

a.ross’s picture

@ZeiP: ah, that's why it wasn't working on one of our servers...

A possible workaround is to use ini_set('user_agent', 'PHP'), but only when the user agent isn't set and possibly also only when PHP < 5.3.11 (or 5.4.0, which also has the bug) is used. I don't like the idea of changing PHP configuration on the fly, but as a workaround for such an important issue I guess it's acceptable.

a.ross’s picture

Here's an updated patch with a load of documentation.

a.ross’s picture

Removed a trailing space and split the documentation in 2 sentences.

roball’s picture

Priority: Major » Normal
Status: Reviewed & tested by the community » Active

It seems this is no more necessary:

[root@my_server ~]# php -r 'ini_set("user_agent", ""); @file_get_contents("http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl"); print_r($http_response_header);'
Array
(
    [0] => HTTP/1.1 200 OK
    [1] => Date: Sun, 25 Aug 2013 18:17:53 GMT
    [2] => Accept-Ranges: bytes
    [3] => Content-Length: 10201
    [4] => Last-Modified: Fri, 28 Jun 2013 20:27:21 GMT
    [5] => Server: Europa
    [6] => Connection: close
)
[root@my_server ~]# php -r 'print "user_agent: \"" . ini_get("user_agent") . "\"\n";'
user_agent: ""
a.ross’s picture

whoa! Did they just change configuration on a whim? Or were you perhaps connecting to a different server than I? Maybe they start blocking requests without User-Agent header when their system load is high?

Anyway this feels highly suspicious to me. I'd rather not change the patch until it has been thoroughly established that they do not require it anymore.

a.ross’s picture

Status: Active » Reviewed & tested by the community

Have recently tested again and I'm still getting HTTP 500 responses when not using the User-Agent header (occasionally I do get a 200, oddly). Setting back to RTBC

pedrosp’s picture

I had the same problem, maybe because of using a NGINX server, however the #6 patch solve my problem.
However I had to "manual patch" against last DEV, because the function to patch had a new "if" before to check if the server is SOAP ready.

roball’s picture

Status: Reviewed & tested by the community » Needs work

Ah, then I would suggest to re-post the patch to work with current 7.x-1.x-dev.

dwkitchen’s picture

Status: Needs work » Postponed (maintainer needs more info)
a.ross’s picture

It's been 7 years, but what info do you need?

dwkitchen’s picture

Status: Postponed (maintainer needs more info) » Fixed

Should have been keeping at as need work - which I have now done as the patch was not applying.

  • dwkitchen committed 66c2d52 on 7.x-1.x authored by a.ross
    Issue #2001598 by a.ross, dwkitchen: VIES load balancers require the...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.