Jump to content
Welcome to our new Citrix community!

ntCoent-Length response header Issue


Sal Dominguez

Recommended Posts

I have been trying to get a better understanding on how the ADC Netscaler handles Content-Length response headers work and how I can make adjustments to them. I noticed that the response header will show two of the content-length headers, one corrupted (ntCoent-Length).

 added.thumb.JPG.d9b52f08a706e6cd83b2341663bf4013.JPG 

 

Is there is a way to remove the misspelled header or make is so its not returned at all?  From what I am seeing on other threads on the internet this is similar to what Nginx will do automatically. I am wondering the why NetScaler keeps the Content-Length header from the original response object. Is it because we have rule precedence issue and it first copies all headers then applies gzip? Is there a way to rewrite this? I did make an attempt to rewrite this with HTTP.RES.HEADER("Content-Length").EXISTS, then removing the content-length header the problem is if the http response is not using gzip/compression the response hangs indefinitely. I am banging my head on this one.

 

removed.thumb.JPG.6f73a49b28573223c7d25a3e486c4818.JPG

 

Any help or shared knowledge on this would be appreciated. 

Link to comment
Share on other sites

Hey,

 

Which service did you publish via ADC?

I had the same problem with Citrix Files, formerly Sharefile, and Microsoft Exchange when sending large attachments.


Please check this, perhaps it helps you:  

The following knob will disable the new functionality to handle large POST request.

nsapimgr_wr.sh -ys arg1=0 -ys arg2=1 -ys arg3=16 -ys call="set_sso_post_data_handler"

Rollback command for the same is given below:
nsapimgr_wr.sh -ys arg1=1 -ys arg2=1 -ys arg3=16 -ys call="set_sso_post_data_handler"

Source: https://support.citrix.com/article/CTX225681

 

Cheers,

Daniel

Link to comment
Share on other sites

Hi Daniel, Thanks for the response.

 

This is not for any type of service being published, instead a custom api that we are using.

 

I have not tried the knob, I am not apposed to the idea and I did see that article. I was just not sure how it would impact other services on the ADC and I was hoping there was a solution that I could use for a specific virtual service instance.

Link to comment
Share on other sites

The original content length header is kept, corrupted and therefore ignored. There is no reason to remove it.  The corrupted header will be ignored and the original header should not be a problem for the receiving client.  The new header will reflect the current optimized size if needed. If you don't want a new content-length returned at all, then a chunked response would be required. (But the original-but-now-corrupted headers are usually included for debugging and to avoid changes to certain checksums.)

 

If you are having issues with responses, then changes might be needed. But if you are just trying to remove the original/modified headers, I think you may be creating a problem that doesn't need to be solved.  There shouldn't be an issue with leaving this modified header in place.  The rewrite policy is not removing the header that you think you are in a way that is compatible with the traffic handling.  

 

A variety of features on the ADC can result in optimizations resulting in the content length being modified and so a new content length header is inserted.

Features such as compression, FEO, and a variety of other optimizations.

Features such as AppFw corrupts the original header and omits a new content-length header as the responses will likely be chunked and therefore the length can be variable to avoid creating a non-trackable connection (a response that indicates a content-length but for which the client receives less than communicated).  (As a number of headers can be modified by appfw functions, many of the original headers are either corrupted or modified to x-<original header name> while a new header is inserted to mark that the change was made by the appfw or proxy.)

 

https://support.citrix.com/article/CTX211605

 

Issues with zero length posts:  https://support.citrix.com/article/CTX225681 (which includees nsapi command mentioned by Daniel)...but I don't think it applies to your case AND you should be very careful with nsapimgr commands.  

 

There was a Citrix KB article that summarized the changes to headers made by the AppFw feature with an explanation of which headers were modified...but it got pulled recently and is not summarized in the admin guide to the same degree. 

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

12 hours ago, Rhonda Rowland1709152125 said:

The original content length header is kept, corrupted and therefore ignored. There is no reason to remove it.  The corrupted header will be ignored and the original header should not be a problem for the receiving client.  The new header will reflect the current optimized size if needed. If you don't want a new content-length returned at all, then a chunked response would be required. (But the original-but-now-corrupted headers are usually included for debugging and to avoid changes to certain checksums.)

 

If you are having issues with responses, then changes might be needed. But if you are just trying to remove the original/modified headers, I think you may be creating a problem that doesn't need to be solved.  There shouldn't be an issue with leaving this modified header in place.  The rewrite policy is not removing the header that you think you are in a way that is compatible with the traffic handling.  

 

A variety of features on the ADC can result in optimizations resulting in the content length being modified and so a new content length header is inserted.

Features such as compression, FEO, and a variety of other optimizations.

Features such as AppFw corrupts the original header and omits a new content-length header as the responses will likely be chunked and therefore the length can be variable to avoid creating a non-trackable connection (a response that indicates a content-length but for which the client receives less than communicated).  (As a number of headers can be modified by appfw functions, many of the original headers are either corrupted or modified to x-<original header name> while a new header is inserted to mark that the change was made by the appfw or proxy.)

 

https://support.citrix.com/article/CTX211605

 

Issues with zero length posts:  https://support.citrix.com/article/CTX225681 (which includees nsapi command mentioned by Daniel)...but I don't think it applies to your case AND you should be very careful with nsapimgr commands.  

 

There was a Citrix KB article that summarized the changes to headers made by the AppFw feature with an explanation of which headers were modified...but it got pulled recently and is not summarized in the admin guide to the same degree. 

 

 

 

 

 

 

Thank you both I think I have the information I need to move forward.

 

Link to comment
Share on other sites

  • 1 year later...

Is there a way to circle around this issue without doing that nsapimgr_wr.sh command mentioned in CTX225681? We're seeing this behavior only on one LB destination, so I'd love to have a switch / rw policy or sth else that we could bind for only that one entity rather than doing that shell command which affects the whole platform.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...