HTTP ERROR: 400, missing content stream

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Get an account on a Mittwald server
2.Try to do a rawPost to a Solr instance

What is the expected output?
It should just do the post

What do you see instead?
HTTP ERROR: 400 missing content stream

What version of the product are you using? On what operating system?
Linux
php -v
PHP 5.2.6 (cgi) (built: Sep 12 2008 17:23:59)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
    with the ionCube PHP Loader v3.1.32, Copyright (c) 2002-2007, by ionCube Ltd., and
    with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies

Please provide any additional information below.
There is a comment in the php manual:
http://nl.php.net/manual/en/function.stream-context-create.php#90927

And the changelog for the http context options:
http://nl.php.net/manual/en/context.http.php
Notes in the changelog: 5.2.10   The header can now be an numerically indexed 
array .

But the provided patch solves a communication issue between two servers running 
PHP 5.2.6, one Mittwald (client) and a stock Debian server (Solr).

Original issue reported on code.google.com by Tuurlijk...@gmail.com on 22 Jul 2010 at 10:10

Attachments:

• context_header.diff

[GoogleCodeExporter]

Issue 56 has been merged into this issue.

Original comment by donovan....@gmail.com on 2 Dec 2010 at 5:52

[GoogleCodeExporter]

Reiterating comment from issue 56

This problem existed on PHP version >= 5.2.6 and < 5.2.10.  In those versions 
there was a problem where the http context options were not treated as 
documented when curl wrappers were enabled in the compile.

See the comment here: http://www.php.net/manual/en/context.curl.php#85551 

In svn trunk (see svn checkout page:  
http://code.google.com/p/solr-php-client/source/checkout), the code now lets 
you assign a transport implementation to use - it defaults to an HTTP url 
wrapper implementation, but a straight cURL based implementation is provided as 
well. Another alternative would be to implement your own transport.

Original comment by donovan....@gmail.com on 2 Dec 2010 at 6:00

[GoogleCodeExporter]

i was using php 5.3.3 when I saw the issue notes in issue 56

Original comment by lukas.smith@gmail.com on 2 Dec 2010 at 7:05

[GoogleCodeExporter]

Lukas,

Hopefully, it wasn't a regression in PHP. The issues seemed so similar I made 
the logical assumption they were related, sorry if that is not the case.  

Are you still seeing this problem? And if so, can you confirm or deny whether 
changing the code to use an array for the header context option corrected it 
like we see in 5.2.6.  

My best current suggestion is still to switch to the newest code and try using 
one of the Curl based transports:

// the Curl transport creates and reuses a single cURL session handle
// depending on your PHP version may leak memory over a large number of requests
$transportInstance = new Apache_Solr_HttpTransport_Curl();

// the CurlNoReuse transport creates and releases a cURL session handle for 
each request
$transportInstance = new Apache_Solr_HttpTransport_CurlNoReuse();

// a transport instance can either be given to the constructor
$solr = new Apache_Solr_Service(..., $transportInstance);

// or, it can be set at any time
$solr->setHttpTransport($transportInstance);

Original comment by donovan....@gmail.com on 2 Dec 2010 at 7:32

[GoogleCodeExporter]

i have switched off curl wrappers. its experimental anyway. i dont have 
anything but 5.3.3 compiled atm. i will point the author of sfSolrPlugin to 
consider one of the above transports.

Original comment by lukas.smith@gmail.com on 2 Dec 2010 at 7:37

[GoogleCodeExporter]

Using a different http transport, substituting your own, or changing php 
configuration are all workable for this situation. This isn't an issue for the 
majority, so i'm going to mark it won't fix.

Original comment by donovan....@gmail.com on 20 May 2011 at 12:16

• Changed state: WontFix