Sham has asked for the wisdom of the Perl Monks concerning the following question:

Hi all, I am using Net::SSLeay to connect to SSL server. I am generating the fillowing xml request along with specific headers as,
Headers : POST /AUTHORIZE HTTP/1.0 MIME-Version: 1.0 Content-Type: application/PTI42 Content-length: 210 Content-transfer-encoding: text Request-number: 1 Document-type: Request Request : <?xml version="1.0" encoding="UTF-8"?> <Request> <NewOrder> <MessageType>A</MessageType> <BIN>000002</BIN> <TerminalID>001</TerminalID> <AVSzip>33408</AVSzip> </NewOrder> </Request>;
but every time I m getting the HTTP/1.1 400 Bad Request error.

Here I want to mention that all the header fields except "POST /AUTHORIZE HTTP/1.0" are being prepared by Net::SSLeay's make_header method and I am concating "POST /AUTHORIZE HTTP/1.0" to them by using "\r\n". While searching I found that header fields are separated bu CRLF(carriage return and line feed). is it done by \r\n in perl?????

If anybody can tell me where should I concentrate so that I will overcome the problem. Docs says that this error corresponds to " 400 Invalid Request: The server, due to malformed syntax, could not understand the request. " Please advice. Thanks, Sham.

Replies are listed 'Best First'.
Re: HTTP/1.1 400 Bad Request
by oha (Friar) on Aug 29, 2007 at 12:51 UTC
    just a guess but.. are you using the https port? (eg: 443 instead of 80)

    Oha

      Oha, Its SSL connection that I using its always follows the port 443. Thanks, SHAM...
Re: HTTP/1.1 400 Bad Request
by jhourcle (Prior) on Aug 29, 2007 at 12:52 UTC

    You might check your webserver's error logs, and see if there's any additional details in there.

    For the CRLF issue, it's probably best not to use '\r\n', as '\n' is handled differently based on the OS you're using. I typically use "\015\012" for CRLF. (see perlport, 'Newlines' for details)

    If that doesn't work, and you don't have access to the error logs to see what specific part of processing is throwing the error, I'd make sure that the request validates as XML, and against whatever schema you might have. (if that trailing semicolon is part of the message being sent, I'd suggest removing it).