Re: [PHP] curl CUSTOMREQUEST

[Richard Lynch]

Juan Nin wrote:
 I saw a post at http://www.php.net/manual/en/ref.curl.php where it says:

 Using the customrequest for a complete post is wrong. Libcurl will add
 a partial url, the http version and the standard headers after the post
 data - while this works with a non-persistent connection and an apache
 web server, it may fail under different conditions

 Does anybody know a bit more on this?? (I sent an e-mail to the one
 who posted it, but the address does not longer exist)

I'm not sure this qualifies as knowing a bit more but...

I believe the key word you are missing in the statment is 'post', as in
POST, as in $_POST variables, which you haven't tested at all in your
script.

As I understand it, just based on reading the same words you are reading,
the issue is that you are sending some extra bogus headers to the
web-server, in the wrong order, after the POST data, if you do a
customrequest for a complete post (whatever that all means).

Now, I'm not 100% sure on this part, but I think in an HTTP POST, the
exchange looks something like this:

---
shell telnet example.com 80
* Trying aaa.bbb.ccc.ddd...
* Connected to example.com.
* Escape character is '^]'.
POST /url/to/script.php HTTP/1.0
Host: example.com
Content-length: [insert length of POST data here]

[insert actual POST data here]

* === Stuff printed by the web-server, without the '* ' actually there.

Note the blank line in between the headers (up to Content-length:) and the
actual POST data.

So what they are telling you *NOT* to do is this:

shell telnet example.com 80
Trying aaa.bbb.ccc.ddd...
Connected to example.com.
Escape character is '^]'.
POST /url/to/script.php HTTP/1.0
Host: example.com
Content-length: [insert length of POST data here]

[insert actual POST data here]
POST /url/to/script.php HTTP/1.0
Host: example.com
Content-length: [insert length of POST data here]


As you can see, bogus headers are getting sent to the server after the
POST data of the specified length was sent.

I don't think it applies at all in GET request, though that may be my
mis-interpretation.

At any rate, if my theory is correct, we can then see what the business
about non-persistent connections and an apache web server mean:

Since the connection is non-persistent, those bogus headers won't be
mistakenly believed to be part of the *NEXT* request in a persistent
connection.

In other words, if you threw in a Keep-alive:  header in the example
POST exchanges above, the extra bogus headers would suddenly become
crucial -- Apache would, correctly, assume they are part of your *NEXT*
request to the web-server on this persistent connection you are using to
send request after request to the web-server.

And, the 'works on apache' simply means that Apache correctly gets only
the POST data up to the Content-length:  specified, and then then pretty
much ignores the bogus headers you tacked on at the end, which it really
shouldn't do, if it wanted to be real persnickety about what is a valid
HTTP request, since you *are* sending bogus headers after your request.

Now, the upshot of all this, if my theory is correct, is this:
If you get it to work on a specific Apache server, and if you document the
fact that trying to use persistent connections *WILL* fail miserably, and
if you are sure that your code won't be used to try this with other web
servers where they might not ignore the bogus extra headers...  It will
work okay, probably, for the rest of time.  But you'd want to document
it as a rather fragile hack that happens to work, rather than the right
way to do things.

Disclaimer: I have no idea what the 'customrequest' part of the message
means, nor how you would do it after a 'complete post' so I may be
completely full of [bleep] in this missive...  'customrequest' could, I
guess, mean that you've got some custom code in Apache and in your
'browser'  (or other programmed client) to do something that is neither
POST nor GET but is some other kind of exchange you set up just for
yourself like FOO -- which is just like GET or POST, only not, because
*you* define the behaviour of your web server and your client for FOO
requests, whatever those might be.  Sounds fun, if I had a lot of hours to
play with it.

-- 
Like Music?
http://l-i-e.com/artists.htm

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] curl CUSTOMREQUEST

[Juan Nin]

I saw a post at http://www.php.net/manual/en/ref.curl.php where it says:

Using the customrequest for a complete post is wrong. Libcurl will add
a partial url, the http version and the standard headers after the post
data - while this works with a non-persistent connection and an apache
web server, it may fail under different conditions

Does anybody know a bit more on this?? (I sent an e-mail to the one
who posted it, but the address does not longer exist)

I tested the following code and didn't experience any problem:

?

$url =  http://www.mydomain.com;;

$request = GET / HTTP/1.1\r\n.
   Host: www.mydomain.com\r\n\r\n;
   
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_TIMEOUT, 15);
curl_setopt ($ch,CURLOPT_CUSTOMREQUEST , $request);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$reply = curl_exec($ch);
curl_close ($ch);

echo 'pre';
echo $reply;

?

but using ngrep on a server of mine I can see this as the request:

GET / HTTP/1.1.
Host: www.mydomain.com.
.
 / HTTP/1.1.
Host: www.mydomain.com.
Pragma: no-cache.
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*.


may be this is what he's talking about when he says about the data
libcurl will add?

does anybody know under which circumstances may this fail??

thanks in advance,

Juan

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php