Forum Discussion
Brian_Ott_11267
Nimbostratus
NimbostratusRemoving extra \r\n
We're finding that when we use the bigip there is an extra \r\n added to the request. This causes problems mainly with POST requests with our application. I was directed by support that an iRule may beable to do this. I believe the BigIP automatically adds an extra \r\n (or crlf) to the request, as mentioned in SOL2167:
BIG-IP automatically translates any instance of \n in the specified command to \r\n and will automatically add an additional \r\n sequence at the end of the request.
We need to remove that extra bit. I've asked if there is a way to do this internally without an iRule, I was surprised when there was not. We experienced the same issue with a Netscaler, and was able to turn it off with a simple flag.
How do I go about making an irule to do this? I assume with http::payload or something similar. But I am not sure of the exact context.
-Brian.
9 Replies
- The solution you reference very specifically refers to HTTP health monitors originating from the BIG-IP, not to requests passing through it. BIG-IP won't add an extra \r\n to a request passing through it. If your application is returning extra \r\ns, or your client is adding them, we can remove them though.
Just so we're all on the same page, please could you attach tcpdumps of the issue on the external and internal side? Please make sure you don't have any sensitive information, such as passwords, in these dumps. 
Brian_Ott_11267I spoke to support about it, I understand, I was hoping it would be simplier than that. I had thought this would be a slightly more common issue, but apparently not. Getting tcpdumps of this problem is extrmely difficult. I will post them when I get them.- Brian_Ott_11267Also there is only one side, internal. We are using it in one arm mode.
I appreciate the assistance and will post the tcpdumps asap. - I've anecdotally heard of certain applications which lie about their content-length. More specifically, they're off by two, since they state a content-length up-front, then deliver the data, and follow it with a \r\n - which is not legal.
Please could you tell me what application this is? Is it off-the-shelf? If so, we can make an argument for a native method to strip extra trailing CRLFs off the response, rather than a rule. I know one of my colleagues was talking about a rule just last week to gather the content-length and strip off the extra trailing CRLF in a faulty application. - Brian,
One last thing: which version are you running? If the \r\n is following POST data on the client request, we might be able to work around it simply by enabling http pipelining on the http profile, but I'm not positive. bl0ndie: any thoughts?
Do you get any messages in your ltm logs about EV_INGRESS_DATA during state ST_HTTP_PREPEND_HEADERS? - Brian_Ott_11267We're running 9.0.3. Which has pipelining enabled by default, I believe.
Here is a pic of the http header capture on one of the POSTs. They all look basically the same with the same number of carriage returns, whether I use the LB or not. Does this have an extra \r\n?
I thank you for your assistance.
-Brian. - Brian_Ott_11267Also, there are no messages in the LTM logs.
If you need more info, please let me know. - Brian_Ott_11267As far as I can tell, the http header looks normal. I am not sure where else to look in the tcpdump besides what I posted. I tried posting on a totally different website and it looks pretty much the same. So I would say our issues are not related to the \r\n like we had thought. Unless anyone else sees an issue with the short capture I showed here, or can suggest where else to look in the dump for such things.
Thank you once again. - Brian_Ott_11267By the way, rapmaster, its mostly basic javascript/html. Its backended by an application coded in another language called Magic. Which may do other things. I am not a programmer so I don't know the details.
I just know we had an issue with people trying to POST with our old netscaler and it was because of an extra \r\n. Details are a bit fuzzy since I was not involved in the initial issue(this was several years ago).
Maybe that extra \r\n after Cache-Control:, in my picture, is the extra bit that is causing the problem? Or is that standard? If not, what kind of iRule would you suggest?
-Brian.
