In the following Nstrace snippet, we could see the Client has sent the 1 Byte HTTP data  and for which, NetScaler has sent RESET to Client with the RESET code as win=213280 as shown below:






You could also see the counter "http_tot_onebyte_baddata1" is getting increase in the newnslog.

[hariharana@sjanalysis-1 /upload/ftp/var/nslog]$ 

  Index   rtime totalcount-val      delta rate/sec symbol-name&device-no
     54  133028          26342          1        0 http_tot_onebyte_baddata1
     55   56012          26343          1        0 http_tot_onebyte_baddata1
     56   98021          26345          2        0 http_tot_onebyte_baddata1
     57   63014          26346          1        0 http_tot_onebyte_baddata1
     58   70015          26347          1        0 http_tot_onebyte_baddata1
     59   14003          26348          1        0 http_tot_onebyte_baddata1
     60  385083          26349          1        0 http_tot_onebyte_baddata1
     61   21004          26350          1        0 http_tot_onebyte_baddata1
     62   42009          26351          1        0 http_tot_onebyte_baddata1
     63   14003          26352          1        0 http_tot_onebyte_baddata1

Issue is fixed in 11.1 build 59 and 12.0 build 59

NOTE: 12.0 build 58 doesn’t has a fix. Only 12.0 build 59 has a fix. 
 

---

Problem Cause

Its a known issue. 

Root Cause:
===========

The TCP RST from NetScaler is due to HTTP code block which considers 1 byte HTTP packet as bad data ( as highlighted in the below nstrace snippet ) and drops the packet/connection and sends a TCP Reset. This code is disabled by default and cannot be enabled/disabled through external means. 

However, the buffer over run issue has triggered the HTTP code block to reset the connections.

We have also confirmed the counter "http_tot_onebyte_baddata1" is getting incremented. Which confirms that NetScaler has RESET the connection since it has considered the 1 byte HTTP data as a BAD data.


Please find the detailed explanation for the TCP connection reset and Buffer overrun as stated below:
 
 
The TCP RST from NetScaler is due to HTTP code block which considers 1 byte HTTP packet as bad data and drops the packet/connection and sends a TCP Reset. This code is disabled by default and cannot be enabled/disabled through external means.
 
How this code block got enabled?
 
We see that this code block got enabled in  Netscaler due to buffer overrun in variable above the variable guarding this block. We are only discussing the reason for this buffer overrun.

This buffer is used for generating the URL for 302/307 responses which is done for redirectURL responses.
 
This has nothing to do with the current POST request URL where the problem is seen as this POST request URL doesn’t contain any special character. There could have been some URL , which caused redirectURL code to cause the buffer overrun.
 
What can cause this buffer run ?
 
We see most of the code has properly boundary checks when generating this redirectURL. This buffer is 2048 bytes. But there is issue in code when some parts of the incoming URL that gets appended to redirect message need to be encoded to make the URL safe (eg: < > etc are present), then this can cause buffer overrun. The exact size that URL which caused the original buffer overrun once, Only thing we can be sure is that the incoming URL was < 2048 bytes and after encoding, the size of the URL went beyond the buffersize of 2048 bytes.
 
In the below example, the URL contains special character <>, NetScaler has performed URL encoding before giving the redirect message to user. The size of the encoded URL has exceeded 2048 bytes and this has caused the buffer overrun to occur.
 
This needs to happen only once and the variable gets corrupted.

# curl -v "10.102.34.154:8123/<abc>"
< HTTP/1.1 302 Object Moved
< Location: https://10.102.34.154:8123/%26lt;abc%26gt;
< Content-Type: text/html
< Cache-Control: private
< Connection: close
 
 
The buffer overrun occurs if any of the following conditions have met: 

1. Redirect URL should be configured and Vserver should be down/LB should fail
2. Redirect URL shouldn’t have a path or prefix i.e. “example.com” will cause issue but not “example.com/” nor “/default.html”
3. Incoming URL + configured redirect URL together should be less than 2048 bytes
4. Incoming URL should have components which must be encoded (able to recreate the issue mainly with special characters “< >” )
5. Incoming URL encoded + configured redirect URL should be > 2048 bytes.