Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

NOTE: Although there's some PHP code below, I really believe this belongs to ServerFault more than StackOverflow, esentially, because this worked and it stopped working after we changed servers.

I have the following situation:

  • There's 2 public websites with different functionalities (UPDATE: both websites are on the same physical server). A user can fill up a huge signup form in Website A to get registered to website B.
  • When a user registers in Website A, I send an Ajax request to a PHP script in Website A to validate the data.
  • This script is esentially a proxy that sends all that data to Website B, and B responds with "OK", or with a bunch of validation errors. It only exists because I can't do cross-domain Ajax directly.
  • All these are HTTP POSTs over SSL

This was working beautifully, until we migrated our server, in the same hosting company, to a bigger one. They hosting people took care of all the migration, and the idea was that the new server would end up with the same configuration as the old one.

Now, after this migration, when the information submitted to the proxy, converted to an "HTTP POST string", takes more than 1024 bytes, the server-side request from Website A to B fails silently. It works, it executes all the lines of code, there are no errors, notices or exceptions that I can see. It just goes all the way to the end, as if website B had responded with an empty string.

If, however, the POST is less than 1024 bytes, it all works great, and I either get the correct validation errors, or "OK" back.

Sending the full POST to Website B directly, without the proxy, works correctly, so the problem is definitely on the proxy call.

I have no rationalization for this behaviour, this makes absolutely no sense to me.

Has any of you ever encountered something like this before?
Any pointers on where I could look?

For reference, this is the proxy code:


$CustomersValidateURL = "https://WebsiteB.com/validatescript";
echo do_post_request($CustomersValidateURL, http_build_query($_POST));

// =========================================================================
function do_post_request($url, $data, $optional_headers = null){

    $params = array('http' => array('method' => 'POST', 'content' => $data));

    if ($optional_headers !== null){
        $params['http']['header'] = $optional_headers;
    }

    $ctx = stream_context_create($params);
    $fp = @fopen($url, 'rb', false, $ctx);

    if (!$fp){
        throw new Exception("Problem with $url, $php_errormsg");
    }

    $response = @stream_get_contents($fp);

    if ($response === false) {
        throw new Exception("Problem reading data from $url, $php_errormsg");
    }

    return $response;
}

This is the result of running a tracepath from that server to "Website B", in the same server:

tracepath customers.xxx.com
 1:  server.xxx.com (208.92.xxx.xxx)      0.144ms pmtu 16436
 1:  server.xxx.com (208.92.xxx.xxx)      0.093ms reached
     Resume: pmtu 16436 hops 1 back 1

share|improve this question
    
Turn your PHP error logging way up and see what your script says. Add a error_reporting(-1); at the top of your code, and watch wherever your error output goes. –  Bill Weiss Jul 19 '10 at 18:41
    
No errors whatsoever, it's pretty weird –  Daniel Magliola Jul 21 '10 at 4:05
add comment

3 Answers

up vote 1 down vote accepted

In the end, I ended up rewriting the script to use cURL instead. I don't know what happened, but cURL works. This is one of the weirdest things I've found...

share|improve this answer
add comment

That smells like an MTU issue between A and B where something is messing up your path MTU discovery. Can you try something like tracepath B from A?

share|improve this answer
    
Both A and B websites are on the same server, so unless i'm misunderstanding the question, I can't really make tracepath B "from A", since it'll be the same as "tracepath B from B" too, I think. Please check the updated version of the original post for the result of the tracepath. Thank you!! –  Daniel Magliola Jul 19 '10 at 18:35
add comment

I once had a similar issue due to a router (Windows 2000's RRAS, it was later fixed in some SP) not properly handling MTUs and simply dropping packets that were too big instead of telling the sender to fragment them in smaller pieces. It was a pain to troubleshoot and a major trouble, as the place was an Internet cafe' and the problem used to surface exactly when a customer was sending a long message from some webmail site.

You should check whether the problem is related to HTTP POSTs or to any data traffic; a simple ping with a payload bigger than 1024 bytes should be enough to verify this.


Update:

Ok, looks like it's not a network problem at all then. Which OS and web server(s) are you using?

share|improve this answer
    
Massimo, thanks for your answer. How did you conclude it's not a network problem? I seem to be running: Linux 2.6.18-194.el5 x86_64 / CentOS release 5.5 (Final). For web servers, they're using LiteSpeed, but they were using that in the server before the migration too. Thanks! –  Daniel Magliola Jul 19 '10 at 18:43
    
@Daniel, it just can't be a network problem between two sites on the same server :-) But it could very well be a configuration issue, some web servers may impose a limit on POST size. –  Massimo Jul 19 '10 at 18:51
    
Could it be some kind of SSL problem? It's definitely configuration, since this worked on the previous server, I just don't know what conf. Limit of POST size: Yes, but it's several megabytes (we checked), definitely not 1kb. Uploading pictures to Website B actually works, this is definitely some kind of limitation we're getting only when the proxy in Web A makes the request. –  Daniel Magliola Jul 19 '10 at 19:05
    
Did you also check the POST size limit on site A? Or any other limit it could be enforcing? –  Massimo Jul 19 '10 at 19:19
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.