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
Comment | File | Size | Author |
---|---|---|---|
#6 | vat_number-vies_user_agent-2001598-6.patch | 1.52 KB | a.ross |
#5 | vat_number-vies_user_agent-2001598-5.patch | 1.52 KB | a.ross |
#1 | vat_number-vies_user_agent-2001598-1.patch | 873 bytes | a.ross |
Comments
Comment #1
a.ross CreditAttribution: a.ross commentedSomething like this:
Comment #2
ZeiP CreditAttribution: ZeiP commentedThis 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.
Comment #3
ZeiP CreditAttribution: ZeiP commentedAdjusting priority and component.
Comment #4
a.ross CreditAttribution: a.ross commented@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.Comment #5
a.ross CreditAttribution: a.ross commentedHere's an updated patch with a load of documentation.
Comment #6
a.ross CreditAttribution: a.ross commentedRemoved a trailing space and split the documentation in 2 sentences.
Comment #7
roball CreditAttribution: roball commentedIt seems this is no more necessary:
Comment #8
a.ross CreditAttribution: a.ross commentedwhoa! 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.
Comment #9
a.ross CreditAttribution: a.ross commentedHave 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
Comment #10
pedrospI 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.
Comment #11
roball CreditAttribution: roball commentedAh, then I would suggest to re-post the patch to work with current 7.x-1.x-dev.
Comment #12
dwkitchen CreditAttribution: dwkitchen at Centarro commentedComment #13
a.ross CreditAttribution: a.ross commentedIt's been 7 years, but what info do you need?
Comment #14
dwkitchen CreditAttribution: dwkitchen at Centarro commentedShould have been keeping at as need work - which I have now done as the patch was not applying.