mapping legacy application requests to http

The simplest thing would be to just replace the incoming payload entirely:

when CLIENT_ACCEPTED {
    log "SocketRequest [TCP::collect] from client [IP::client_addr]"
    TCP::collect
    set hardpath "/jonview_host/connectionview?"
    set usercred "userid=AAAA&password=XXXXX"
    set clientip "ipAddress=[IP::client_addr]&"
}

when CLIENT_DATA {
    log "Payload received: [TCP::payload]"
    set httprequest "GET $hardpath$clientip$usercred&message=\"[TCP::payload]\" HTTP/1.1\r\nHost: myhost\r\nAccept: */*\r\n\r\n"
    log "request built: $httprequest"
TCP::payload replace 0 [TCP::payload length] ""
TCP::payload replace 0 0 $httprequest
TCP::release
}

Where the incoming payload may look something like this (broken out for readability - assume \r\n characters used for newlines):

 

-----------------------------------------------------------------

 

GET / HTTP/1.1

 

User-Agent: curl/7.16.4

 

Host: 10.70.0.196

 

Accept: */*

 

 

-----------------------------------------------------------------

 

You'll replace it with this:

 

-----------------------------------------------------------------

 

GET /jonview_host/connectionview?ipAddress=10.70.0.1&userid=AAAA&password=XXXXX&message="GET / HTTP/1.1 User-Agent: curl/7.16.4 Host: 10.70.0.196 Accept: */* " HTTP/1.1

 

Host: myhost

 

Accept: */*

 

 

-----------------------------------------------------------------

 

You don't have to include the full URL in the request or pool statement because all of the traffic will be going to the pool assigned to the virtual server. Here are a few additional considerations:

1. Assuming it's your intention to send the FULL TCP request payload (method, headers, and all) to the server, I'd think you might want to at least URI-encode the (malformed) message query string, but that I suppose depends on your application.

2. If the client is sending properly formatted HTTP requests, and you DON'T need the full TCP request payload, but rather just the HTTP payload (everything after the HTTP headers), then this would all be much easier to do with HTTP commands.

thank you Kevin,

 

I'll give it a try.

 

> 2. that is not the case. I know it would be easier that way.

 

Urs