in reply to [SOLVED] Basic HTTP problems

The sid returned is a 32 characters long string. I believe that Python might add a prefix so the programmer made sure only the returned 32 chars are taken. Anyway, with or without substring in Perl, the sid string is exactly the same (len of 32), and the result is the same. The issue is not there.

$res->code is 200 for each request. There is no HTTP error.

With the Python script, the server is sending the right information.
With the Perl script, the server is acting like it is not authenticated.

The problem seems to rely more on what an how $ua->post is actually sending the data. The tcpdump shows it is different, where it should be the same.

Also, maybe each request is not considered in the same HTTP session in Perl?

Replies are listed 'Best First'.
Re^2: Basic HTTP problems
by Corion (Patriarch) on Feb 05, 2021 at 14:54 UTC

    Consider inspecting the actual data that goes over the wire. The tcpdump output does not show the data.

    You want to print the request from both programs and compare that. Either create the POST request separately and dump it (using HTTP::Request::Common maybe):

    print $req->as_string;

    ... or add dumping of sent and received data:

    $ua->add_handler("request_send", sub { shift->dump; return }); $ua->add_handler("response_done", sub { shift->dump; return });

    I'm sure that Python also has ways to show the data that goes out and comes back in.

      The handlers are so precious advice, thank you!

      It allowed me to discover that the sid has hidden control chars before the 32 chars, so I fixed that.
      BUT that does not fix the issue.

      However after sending the first sid for authentication, the server is sending a cookie with another sid, so I need to probably deal with that. Also, I need to do the same handler trick to the python code, and that will definitively help to solve the problem.

      EDIT: it was the cookies. Adding a cookie jar did the trick!


      Thank you!
      When troubleshooting issues like this, always look at server logs also. Looks like this was an authentication-related issue due to the absence of cookies, and the server will have logged it as such. You really can't tell much from TCPDUMP.

        Yes, this is good advice, when you have access to it.

        In this case, the handler fonctions were exactly what I needed: to know what is being sent and received as tcpdump misses al lot of data as you pointed out.