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
