Groups > comp.lang.php > #13555 > unrolled thread

PHP-SOAP/5.4.21 SoapClient terminating POST without waiting for reply, but still complaining "error fetching http headers".

Started by	ghpille@gmail.com
First post	2014-05-09 07:24 -0700
Last post	2014-05-19 12:58 -0700
Articles	12 — 4 participants

Back to article view | Back to comp.lang.php

#13555 — PHP-SOAP/5.4.21 SoapClient terminating POST without waiting for reply, but still complaining "error fetching http headers".

From	ghpille@gmail.com
Date	2014-05-09 07:24 -0700
Subject	PHP-SOAP/5.4.21 SoapClient terminating POST without waiting for reply, but still complaining "error fetching http headers".
Message-ID	<469c3247-13da-4ea2-a0f0-61bacc2a0929@googlegroups.com>

We have a problem with a specific soap request to one of our webservices, and my impression is that PHP is misbehaving on the TCP level.  I'll show you a tcpdump of such session.   Can anyone tell me what could be the reason for PHP to behave in this way, unless we've stumbled on a bug?

Mark the FIN flag in the third packet, to which our HAProxy server reacts with three ReSeTs.  The post never reaches the destination, which is understandable.


17:42:00.405859 IP we?????.?????.be.60083 > rmgdmzhaproxyip173.dmz.local.http: Flags [.], seq 1804:9044, ack 21378, win 454, options [nop,nop,TS val 1818030407 ecr 2095496264], length 7240
E..|n.@.@.Ro...R.......P...I..](....y......
l\.G|..HPOST /amehoela-jobcv-dao/serviceTeamFacade HTTP/1.1
Host: we?????.?????.be
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.4.21
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Content-Length: 8300

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://facade.dao.??????.??????.be/"><SOAP-ENV:Body><ns1:saveJob><arg0><path>/regio/jobs</path><application>JOBCV</application><userIdentifier>14069</userIdentifier><impersonatorIdentifier/><language>nl</language><site>JOBVLAN</site></arg0><arg1><totalCount>true</totalCount><applications>false</applications><basics>true</basics><company>false</company><contact>false</contact>
snip loads of XML
snip loads of XML
snip loads of XML
<descriptions><name>remunerationDescription</name><value>test</value></descriptions><educations><educationCode>F</educationCode></educations><experience>N</experience><externalJobCode>test</externalJobCode><functionCategories><functionCategory>0100</functionCategory></functionCategories><functionTy


17:42:00.405883 IP we???????.??????.be.60083 > rmgdmzhaproxyip173.dmz.local.http: Flags [P.], seq 9044:9996, ack 21378, win 454, options [nop,nop,TS val 1818030407 ecr 2095496264], length 952
E...n.@.@.j....R.......P......](....`......
l\.G|..Hpe>x:SE</functionType><jobDescriptionText>test</jobDescriptionText><jobSchedule>x:FULL</jobSchedule><jobTitle>test</jobTitle><jobType>x:TEMP</jobType><language>nl</language><location><address><city>Gemeentenaam</city><countryCode>BE</countryCode><department>West-Vlaanderen</department><postalCode>8800BE</postalCode><region>VLAAMS GEWEST</region></address><cityCode>8800BE</cityCode><departmentCode>BE25</departmentCode><districtCode></districtCode><regionCode>BE2</regionCode></location><remunerationDescription>test</remunerationDescription><requiredQualifications>test</requiredQualifications><roulartaJobCode></roulartaJobCode><sector>1700</sector></jobDescriptions><logo><detail><language>nl</language><name>job--nl</name><path>/2014/05/07/6e204c2badbb0cbce7b887b8f813f353/eee99b2a98dfda49aa7e98be97f3110c.gif</path></detail><details><language>nl</language><name>job--nl</name><path>/2014/05/07/6e204c2badbb0cbce7b887b8f813f353/eee99b2a98d

17:42:00.405895 IP we??????.??????.be.60083 > rmgdmzhaproxyip173.dmz.local.http: Flags [FP.], seq 9996:10320, ack 21378, win 454, options [nop,nop,TS val 1818030407 ecr 2095496264], length 324
E..xn.@.@.mm...R.......P...I..](....^......
l\.G|..Hfda49aa7e98be97f3110c.gif</path></details></logo><numberToFill>0</numberToFill><ownerSite>JOBVLAN</ownerSite><packageProduct><packageCode></packageCode><productCode></productCode></packageProduct><shielded>false</shielded><status>PENDING</status><version>6</version></arg2></ns1:saveJob></SOAP-ENV:Body></SOAP-ENV:Envelope>

17:42:00.406120 IP rmgdmzhaproxyip173.dmz.local.http > we??????.??????.be.60083: Flags [R], seq 2711706920, win 0, length 0
E..(..@.@..........R.P....](....P...h.........
17:42:00.406135 IP rmgdmzhaproxyip173.dmz.local.http > we??????.??????.be.60083: Flags [R], seq 2711706920, win 0, length 0
E..(..@.@..........R.P....](....P...h.........
17:42:00.406179 IP rmgdmzhaproxyip173.dmz.local.http > we??????.??????.be.60083: Flags [R], seq 2711706920, win 0, length 0
E..(..@.@..........R.P....](....P...h.........




php-soap.x86_64                           5.4.21-2.el6.remi              @remi

[toc] | [next] | [standalone]

#13556

From	Salvatore <sal@yojimbo.hack.invalid>
Date	2014-05-09 14:27 +0000
Message-ID	<lkioka$2kga$1@news.tokachu.com>
In reply to	#13555

On 2014-05-09, ghpille@gmail.com <ghpille@gmail.com> wrote:
> We have a problem with a specific soap request to one of our webservices,
> and my impression is that PHP is misbehaving on the TCP level.  I'll show
> you a tcpdump of such session.   Can anyone tell me what could be the
> reason for PHP to behave in this way, unless we've stumbled on a bug?
> [snip]

The PHP binary doesn't assemble TCP packets itself. I think it's a
problem with either the host machine's TCP stack or some firewall
between you and the SOAP server.

-- 
Blah blah bleh...
GCS/CM d(-)@>-- s+:- !a C++$ UBL++++$ L+$ W+++$ w M++ Y++ b++

[toc] | [prev] | [next] | [standalone]

#13586

From	ghpille@gmail.com
Date	2014-05-10 11:16 -0700
Message-ID	<7852a1c8-87ea-4fd2-8ff1-592496072ce4@googlegroups.com>
In reply to	#13556

Op vrijdag 9 mei 2014 16:27:22 UTC+2 schreef Salvatore:
> On 2014-05-09, ghp....@gmail.com <ghp....@gmail.com> wrote:
> 
> > We have a problem with a specific soap request to one of our webservices,
> 
> > and my impression is that PHP is misbehaving on the TCP level.  I'll show
> 
> > you a tcpdump of such session.   Can anyone tell me what could be the
> 
> > reason for PHP to behave in this way, unless we've stumbled on a bug?
> 
> > [snip]
> 
> 
> 
> The PHP binary doesn't assemble TCP packets itself. I think it's a
> 
> problem with either the host machine's TCP stack or some firewall
> 
> between you and the SOAP server.
> 
> 
> 

There's nothing in between those two machines, but I'll doublecheck.  I hope you're right, it gives me somewhere else to check for known bugs, I couldn't find any like this in connection with php-soap.

[toc] | [prev] | [next] | [standalone]

#13587

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2014-05-10 16:14 -0400
Message-ID	<lkm1ap$7bh$1@dont-email.me>
In reply to	#13586

On 5/10/2014 2:16 PM, ghpille@gmail.com wrote:
> Op vrijdag 9 mei 2014 16:27:22 UTC+2 schreef Salvatore:
>> On 2014-05-09, ghp....@gmail.com <ghp....@gmail.com> wrote:
>>
>>> We have a problem with a specific soap request to one of our webservices,
>>
>>> and my impression is that PHP is misbehaving on the TCP level.  I'll show
>>
>>> you a tcpdump of such session.   Can anyone tell me what could be the
>>
>>> reason for PHP to behave in this way, unless we've stumbled on a bug?
>>
>>> [snip]
>>
>>
>>
>> The PHP binary doesn't assemble TCP packets itself. I think it's a
>>
>> problem with either the host machine's TCP stack or some firewall
>>
>> between you and the SOAP server.
>>
>>
>>
>
> There's nothing in between those two machines, but I'll doublecheck.  I hope you're right, it gives me somewhere else to check for known bugs, I couldn't find any like this in connection with php-soap.
>

There is a LOT between the client and the server scripts.  PHP is only a 
small part of it.

Salvatore is correct - PHP has nothing to do with the PHP packets 
itself.  And I would be willing to bet the problem is NOT in your TCP/IP 
stack - such a problem wouldn't show up only on your machine with this 
particular SOAP request.

My bet is you're assembling the SOAP requests incorrectly.  Another 
option would be your SOAP client isn't decoding them properly.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13588

From	ghpille@gmail.com
Date	2014-05-11 04:20 -0700
Message-ID	<41f5d4c1-fc73-45ac-afb4-8072de806fc6@googlegroups.com>
In reply to	#13587

> 
> There is a LOT between the client and the server scripts.  PHP is only a 
> 
> small part of it.
> 
> 
> 
> Salvatore is correct - PHP has nothing to do with the PHP packets 
> 
> itself.  And I would be willing to bet the problem is NOT in your TCP/IP 
> 
> stack - such a problem wouldn't show up only on your machine with this 
> 
> particular SOAP request.
> 
> 
> 
> My bet is you're assembling the SOAP requests incorrectly.  Another 
> 
> option would be your SOAP client isn't decoding them properly.
> 
> 
> 
> --

The soap request is "assembled" by Symfony2, if I'm not mistaken.

Suppose something is wrong with the soap-envelope.  How could that make TCP misbehave?

I ran tcpdump on the soap-client-machine.  It is on that machine that the fin flag in the third packet was set.

I'll concentrate on the TCP stack.   Where do I start?   vmxnet3?

[toc] | [prev] | [next] | [standalone]

#13593

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2014-05-11 08:22 -0400
Message-ID	<lknq2l$1co$1@dont-email.me>
In reply to	#13588

On 5/11/2014 7:20 AM, ghpille@gmail.com wrote:
>
>>
>> There is a LOT between the client and the server scripts.  PHP is only a
>>
>> small part of it.
>>
>>
>>
>> Salvatore is correct - PHP has nothing to do with the PHP packets
>>
>> itself.  And I would be willing to bet the problem is NOT in your TCP/IP
>>
>> stack - such a problem wouldn't show up only on your machine with this
>>
>> particular SOAP request.
>>
>>
>>
>> My bet is you're assembling the SOAP requests incorrectly.  Another
>>
>> option would be your SOAP client isn't decoding them properly.
>>
>>
>>
>> --
>
> The soap request is "assembled" by Symfony2, if I'm not mistaken.
>
> Suppose something is wrong with the soap-envelope.  How could that make TCP misbehave?
>
> I ran tcpdump on the soap-client-machine.  It is on that machine that the fin flag in the third packet was set.
>
> I'll concentrate on the TCP stack.   Where do I start?   vmxnet3?
>

Start by debugging your problem and determining the failing component. 
PHP has NOTHING to do with the format of a TCP/IP packet.

Once you've determined the failing component, ask in a forum or 
newsgroup appropriate to the failure.

If you are unable to do that, I would suggest hiring a consultant to 
assist you (and no, I am not available).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13602

From	ghpille@gmail.com
Date	2014-05-11 23:48 -0700
Message-ID	<879b40da-bf4e-453c-be2b-9a4ed877bb03@googlegroups.com>
In reply to	#13593

Op zondag 11 mei 2014 14:22:47 UTC+2 schreef Jerry Stuckle:
> 
> 
> 
> If you are unable to do that, I would suggest hiring a consultant to 
> 
> assist you (and no, I am not available).
> 

Why on earth would one hire a consultant while one can get such valuable advice as yours for free in the newsgroups?

[toc] | [prev] | [next] | [standalone]

#13605

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2014-05-12 08:10 -0400
Message-ID	<lkqdns$olo$1@dont-email.me>
In reply to	#13602

On 5/12/2014 2:48 AM, ghpille@gmail.com wrote:
> Op zondag 11 mei 2014 14:22:47 UTC+2 schreef Jerry Stuckle:
>>
>>
>>
>> If you are unable to do that, I would suggest hiring a consultant to
>>
>> assist you (and no, I am not available).
>>
>
> Why on earth would one hire a consultant while one can get such valuable advice as yours for free in the newsgroups?
>

So you have someone who knows what they're doing.  You obviously have no 
clue.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13589

From	ghpille@gmail.com
Date	2014-05-11 04:28 -0700
Message-ID	<d1dee35c-f356-412f-a5f4-f9e9a1a82dd6@googlegroups.com>
In reply to	#13555

Op vrijdag 9 mei 2014 16:24:32 UTC+2 schreef ghp...@gmail.com:

Could vmxnet3 be involved?   Or should I look further up (or down?) the stack?

# modinfo vmxnet3
filename:       /lib/modules/2.6.32-358.2.1.el6.x86_64/kernel/drivers/net/vmxnet3/vmxnet3.ko
version:        1.1.29.0-k
license:        GPL v2
description:    VMware vmxnet3 virtual NIC driver
author:         VMware, Inc.
srcversion:     300574F157A2E481CA33E17
alias:          pci:v000015ADd000007B0sv*sd*bc*sc*i*
depends:        
vermagic:       2.6.32-358.2.1.el6.x86_64 SMP mod_unload modversions

[toc] | [prev] | [next] | [standalone]

#13594

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2014-05-11 08:23 -0400
Message-ID	<lknq4f$1co$2@dont-email.me>
In reply to	#13589

On 5/11/2014 7:28 AM, ghpille@gmail.com wrote:
> Op vrijdag 9 mei 2014 16:24:32 UTC+2 schreef ghp...@gmail.com:
>
> Could vmxnet3 be involved?   Or should I look further up (or down?) the stack?
>
> # modinfo vmxnet3
> filename:       /lib/modules/2.6.32-358.2.1.el6.x86_64/kernel/drivers/net/vmxnet3/vmxnet3.ko
> version:        1.1.29.0-k
> license:        GPL v2
> description:    VMware vmxnet3 virtual NIC driver
> author:         VMware, Inc.
> srcversion:     300574F157A2E481CA33E17
> alias:          pci:v000015ADd000007B0sv*sd*bc*sc*i*
> depends:
> vermagic:       2.6.32-358.2.1.el6.x86_64 SMP mod_unload modversions
>

Ask in an appropriate place.  This is a PHP group (hence the "PHP" in 
its name).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13669

From	ghpille@gmail.com
Date	2014-05-14 02:27 -0700
Message-ID	<6c926bf8-0a42-4598-bd9d-32ac3e2b356d@googlegroups.com>
In reply to	#13555

Op vrijdag 9 mei 2014 16:24:32 UTC+2 schreef ghp...@gmail.com:
> We have a problem with a specific soap request to one of our webservices, and my impression is that PHP is misbehaving on the TCP level.  I'll show you a tcpdump of such session.   Can anyone tell me what could be the reason for PHP to behave in this way, unless we've stumbled on a bug?
> 
> 
> 
> Mark the FIN flag in the third packet, to which our HAProxy server reacts with three ReSeTs.  The post never reaches the destination, which is understandable.


It turns out that the SoapClient is sending data on a half-closed connection.  The server had earlier sent a FIN packet, that had been ACKnowledged by the client.

Now, from a TCP point of view, it is permissible to send data with of before your own FINish.

But POSTing something to which you're expecting a reply, on a half-closed connection?

[toc] | [prev] | [next] | [standalone]

#13746

From	Gerard Henri Pille <ghpille@gmail.com>
Date	2014-05-19 12:58 -0700
Message-ID	<e50905e0-9188-48c8-b35f-fb5f5cf24264@googlegroups.com>
In reply to	#13555

It turned out to be a bug in PHP, which I managed to patch  (that is, if the patch is accepted).

https://bugs.php.net/bug.php?id=67292

[toc] | [prev] | [standalone]

csiph-web

PHP-SOAP/5.4.21 SoapClient terminating POST without waiting for reply, but still complaining "error fetching http headers".

Contents

#13555 — PHP-SOAP/5.4.21 SoapClient terminating POST without waiting for reply, but still complaining "error fetching http headers".

#13556

#13586

#13587

#13588

#13593

#13602

#13605

#13589

#13594

#13669

#13746