[TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER

[Steffen Gebert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

sorry, I haven't monitored this topic until now.

Indeed, we are running "proxy_intercept_errors on", which will catch
errors 500-504 in our configuration.

I could deactivate this globally, but I found this feature pretty nice.
So maybe we just disable it for the that one URL? (which is
/wsdl/tx_ter_wsdl.php or index.php?id=ter ?)

>         location /wsdl/tx_ter_wsdl.php {
>                 proxy_pass      http://backend_srv107;
> 
>                 # disable the interception of error pages sent by the backend server for TER SOAP
>                 # otherwise uploaders cannot see correct error messages (e.g. that no version constraint is set)
>                 proxy_intercept_errors  off;
>         }

Please note that there's a RewriteRule in place on the web server (not
that some get confused):
> RewriteRule ^wsdl/tx_ter_wsdl.php$ typo3conf/ext/ter/tx_ter_wsdl.php [L]

What do you think?

Kind regards
Steffen

- -- 
Steffen Gebert
TYPO3 Server Administration Team Member

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org

My wish list:
https://www.amazon.de/registry/wishlist/922E3JYSQ7CV/ref=cm_wl_sb_v?sort=priority

On 9/17/13 5:12 PM, Jigal van Hemert wrote:
> Hi,
> 
> On 16-9-2013 23:45, Helmut Hummel wrote:
>> On 16.09.13 20:50, Jigal van Hemert wrote:
>>
>>> I'm not convinced it's a problem in the TER on the server part.
>> But it is! The problem is not only the TER Serverpart but also the
>> webserver configuration and the fact, that PHP sends a 500 status code
>> for SoapFaults by default.
>>
>> There was a hack in TER Server to circumvent this PHP behaviour but
>> this obviously did not work.
>>
>> In combination with a special default (HTML) error page configured in
>> the webserver when status code is 500, this lead to the meaningless
>> error messages in (all) SoapClients.
> 
> From what I now understand the problem is the fact that the web server
> (the Nginx part) catches the 500 status and outputs a special error page
> instead of what PHP sent.
> 
> This also explains why the message from TER worked fine on my test TER
> server. I tested with uploading extensions with incorrect and correct
> dependencies from the 4.5 and 4.7 Extension Manager and saw the exact
> messages from (my) TER.
> 
>> A workaround (looks ugly but works) for that is now commited and
>> deployed on typo3.org
>> http://forge.typo3.org/attachments/24980/51654_v2.diff
> 
> Yes, it's quite ugly that it abuses the status 424 (which is for WebDAV
> to indicate that a requested action failed because it depends on another
> action which failed).
> 
> The behaviour of the Nginx server should be changed to not serve that
> document when status 500 occurs.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJSODcNAAoJEIskG/rSlyw4oO4H/005ahhKqu+/Q8vCs20UFHLi
If8gw0tBBLqUpI/Of7/e4+3aE9R/qkH2J8ecwsLIb+ZytuzpU0e/JBNFqOJcf5h/
eBDASIQM0CdYZcwCVdm2t5nxCQaDP2861gBNgkHYvQO5kVLgvJOyr8RwX41kvMFd
p6RxNgHHnBzwPGu9cwfdKT+fVQG8AaG5ouyM6osfdDGzMZC+MiKu529VT4s3EoLz
eL2UOJ8NBy/M09h7FIq0LdbZXvvAzzi8jT3hxcoRKCqlspIZPsFYWCPNjrkE6nAp
PDNbjAWGdogpA4Ar9HXbmS4mjVRBoeHIltCANg9mZd9Vit2a3xqGPlYIPmLrbR8=
=uHI6
-----END PGP SIGNATURE-----