HTTP header "Via:1.1 nc1 (NetCache NetApp/6.0.5P1)" stops IIS6 gzip compression - http-headers

The request I sent is accept gzip but the response is not compressed, instead, I received some header
Via:1.1 nc1 (NetCache NetApp/6.0.5P1)
I guess this is to do with my ISP since it works perfectly on my home computer.
Any idea how to get the response compressed?
Request header
GET /test.aspx HTTP/1.1
Host this.is.example.com
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 (.NET CLR 3.5.30729)
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 300
Pragma no-cache
Cache-Control no-cache
Response header
HTTP/1.1 200 OK
Date Mon, 01 Dec 2008 19:53:40 GMT
Content-Length 6099
Content-Type text/html; charset=utf-8
Cache-Control private
Server Microsoft-IIS/6.0
X-Powered-By ASP.NET
X-AspNet-Version 2.0.50727
Via 1.1 nc1 (NetCache NetApp/6.0.5P1)
Expires 0
Cache-Control no-cache
// I expect content-encoding to be gzip here
Thanks in advance.

There's no mechanism to force response compression. Accept-Encoding: gzip only tells the webserver/proxy that it MAY compress the response, not that it MUST encode the response. There are many webservers and proxies that don't support gzip out of the box, or have it configured off by default.
The Via header that you found is frequently inserted by proxies that connect to the intended webserver on your behalf, and is informational. It's unrelated to your compression woes.

Related

How to Preventing Host Header Attack in Ubuntu Server 14.04

If we send a request from any host like example.com our server gives back a HTTP 1.1 200 OK response status.
In correct condition it should show either 302, 400 or 404 error message (not found response) status. At current condition it is showing 200 OK response message, when its send through our host like xx.xxx.xx.xx.
For example, if we sent this request:
GET /web/ HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (Windows
NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5 Connection: close
Upgrade-Insecure-Requests: 1
We get this response:
HTTP/1.1 200 OK Date: Thu, 02 Mar 2017 15:23:20 GMT Server:
figi_Server X-Frame-Options: deny Strict-Transport-Security: 1 Vary:
Accept-Encoding X-Content-Type-Options: nosniff X-Frame-Options:
sameorigin X-XSS-Protection: 1; mode=block
Using
OS: Ubuntu 14.04.
Web server: Apache 2.2.
Virtual machine running both.
Please go through Screen Shot Of Issue for better Understanding of Issue:

How can I authenticate websocket connection

What is a common approach in authenticating of user session for websocket connection?
As I understand websocket message contains data only with no headers. Thus authorization cookie is not available to server backend. How should application distinguish messages from different clients?
Which websocket server are you using?
if your webserver and websocketserver are the same, you could send the sessionid via websocket and force-disconnect any client that does not send a valid sessionid in his first message.
if your websocketserver parses the HTTP headers sent in the HTTP upgrade request properly, it may also save any cookie. this is what a request of my firefox (version 35) looks like:
GET /whiteboard HTTP/1.1
Host: *:*
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Sec-WebSocket-Version: 13
Origin: *
Sec-WebSocket-Protocol: whiteboard
Sec-WebSocket-Key: iGPS0jjbNiGAYrIyC/YCzw==
Cookie: PHPSESSID=9fli75enklqmv1a30hbdmg1461
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
as you see, the phpsessionid is transmitted fine. check the documentation of your websocketserver if it parses the HTTP headers. remember that cookies will not be sent if the websocket's domain differs from the webserver's domain.

Apache 413 Request Entity Too Large with large string

Recently i change to a dedicated server and i start having problems to save large string in a jquery ajax post. in the old server works fine's but in this new server i get an Apache 413 error.
Firebug send this response:
Encabezados de la respuesta
Connection close
Content-Encoding gzip
Content-Length 331
Content-Type text/html; charset=iso-8859-1
Date Mon, 06 Aug 2012 20:53:23 GMT
Server Apache
Vary Accept-Encoding
Encabezados de la petición
Accept */*
Accept-Encoding gzip, deflate
Accept-Language es-MX,es;q=0.8,en-us;q=0.5,en;q=0.3
Connection keep-alive
Content-Length 1105294
Content-Type application/x-www-form-urlencoded; charset=UTF-8
Cookie SpryMedia_DataTables_table-objetos_crear.php=%7B%22iCreate%22%3A1344285216690%2C%22iStart%22%3A0%2C%22iEnd%22%3A10%2C%22iLength%22%3A10%2C%22sFilter%22%3A%22%22%2C%22sFilterEsc%22%3Atrue%2C%22aaSorting%22%3A%5B%20%5B1%2C%22asc%22%5D%5D%2C%22aaSearchCols%22%3A%5B%20%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%5D%2C%22abVisCols%22%3A%5B%20true%2Ctrue%2Ctrue%2Ctrue%2Ctrue%5D%7D; SpryMedia_DataTables_confs-tabla_index.php=%7B%22iCreate%22%3A1344286395266%2C%22iStart%22%3A0%2C%22iEnd%22%3A8%2C%22iLength%22%3A10%2C%22sFilter%22%3A%22%22%2C%22sFilterEsc%22%3Atrue%2C%22aaSorting%22%3A%5B%20%5B8%2C%22desc%22%5D%2C%5B4%2C%22asc%22%5D%2C%5B0%2C%22asc%22%5D%2C%5B1%2C%22asc%22%5D%2C%5B2%2C%22asc%22%5D%5D%2C%22aaSearchCols%22%3A%5B%20%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%2C%5B%22%22%2Ctrue%5D%5D%2C%22abVisCols%22%3A%5B%20true%2Ctrue%2Ctrue%2Ctrue%2Ctrue%2Ctrue%2Ctrue%2Ctrue%2Cfalse%2Ctrue%2Cfalse%5D%7D; PHPSESSID=3d8f502be166becd4e504a438eb2b4ae; chkFiltroCol2=; COL=misconfs; ACCION=CONF_EDITAR_CONTENIDO; CONF_ID=279
Host eduweb.mx
Referer http://myserver.com/edit-article.php
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
X-Requested-With XMLHttpRequest
Googling i found the error was in the size of LimitRequestBody, i change it to 64Mb but i still getting this error.
any ideas how to solve this?
It's what worked for me:
in modsecurity.conf file
On my Ubuntu 14.04 the config file is here but this really depends on the system:/etc/modsecurity/modsecurity.conf
change this two commands to this values:
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 13107200
LimitRequestBody is probably not what you want. That's the request body, not the headers which is what it looks like is too long. Try setting the LimitRequestFieldSize, which by default is 8k, to something larger (Note the warning about precedence about this setting).
You may be bumping into an SSL renegotiate buffer overflow situation. Check your Apache log file. The quick fix if this is the case is to use the SSLRenegBufferSize directive to increase your renegotiate buffer. See SSL Renegotiation with Client Certificate causes Server Buffer Overflow

varnish don't resolve ESI in my localhost

varnish don't resolve ESI in my localhost:
i have similar configuration like other users in apache, but i send/get following headers:
Server Apache/2.2.21 (Debian)
X-Powered-By PHP/5.3.8-2
Content-Encoding gzip
Edge-Control cache-maxage=31536000s
Cache-Control public, max-age=31536000
Pragma public
Expires Tue, 30 Oct 2012 11:41:15 GMT
ProcessID 3918
Etag c2e6665981c6441ab860d12a6853a002
Vary Accept-Encoding
Content-Type text/html; charset=UTF-8
Content-Length 4193
Date Mon, 31 Oct 2011 10:40:54 GMT
X-Varnish 630755530
Age 0
Via 1.1 varnish
Request Headersview source
Host i.host.com
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 Iceweasel/7.0.1
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip, deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection keep-alive
Cookie OAX=1I6M006JYzwABwNj; __utma=164510763.315921951.1317626740.1319722611.1319795071.39; __utmz=164510763.1317626740.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=229641156.678788339.1317628577.1320057939.1320060143.19; __utmz=229641156.1317628577.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); lang=es; __utmc=229641156; __utmb=229641156.4.10.1320060143
If-None-Match c2e6665981c6441ab860d12a6853a002
Cache-Control max-age=0
other user example that works:
Server Apache/2.2.4 (Win32) PHP/5.3.5
X-Powered-By PHP/5.3.5
Set-Cookie lang=es; expires=Mon, 31-Oct-2011 11:46:01 GMT; path=/
Edge-control cache-maxage=31536000s
Cache-Control public, max-age=31536000
Pragma public
Expires Tue, 30 Oct 2012 10:46:01 GMT
ProcessID 3824
Etag f9dcd4b1ec3f40e6763e80a3ba195de3
Content-Type text/html; charset=UTF-8
Transfer-Encoding chunked
Date Mon, 31 Oct 2011 10:46:01 GMT
X-Varnish 630755925
Age 0
Via 1.1 varnish
Connection keep-alive
Cabeceras de la peticiónver fuente
Host t.host.com
User-Agent Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding gzip, deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection keep-alive
Cookie OAX=1I6M001BiwUAB0EE; __utma=164510763.1374034467.1296142874.1319189845.1319204625.107; __utmz=164510763.1319204625.107.79.utmcsr=tamara.eitb.com|utmccn=(referral)|utmcmd=referral|utmcct=/eu/eguraldia/eskia/; __utma=261580168.2132154740.1302611206.1319197586.1320057948.90; __utmz=261580168.1302611206.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); lang=es; __utmb=261580168.1.10.1320057948; __utmc=261580168
i don't know why i receive different headers from varnish...
i get:
Content-Encoding gzip
Vary Accept-Encoding
why i get this headers and the other users no???
both have mod_deflate on...
you´re getting both Content-Encoding and Vary in order to Varnish, an a user-agent, properly handle the request. While Content-Encoding tells Vanish, an a user-agent, that the page content is encoded in a zip format, gzip in your case, the header Vary tells, specially Varnish to cache both versions of the page with or without gzip compression.
If backend is compression encoding aware, it can deliver a version with compression (gzip or deflate) or it can deliver a version withou any compression (text/html for example).
But, to enable ESI processing in varnish, use the esi; command on your vcl file. See this page for more information:

Safari complains: Origin file:// is not allowed by Access-Control-Allow-Origin

My JavaScript Ajax program works fine with FireFox.
It even works OK on iPad!
But when I run it on Safari on Windows 7 - I get the above error.
I am attaching the HttpRequest header and respond.
First the FF data- see below -
I think - not sure - that it shows that the site I am accessing is not blocking me.
Next is the Safari data- see below -
I think that the problem is that Safari adds to the request header a
Origin:file://
I am not sure that this is the problem and I did not find a way to force Safari not to add it.
Thanks for your help
Ori
Here is the FF Data
Response Headers
Date Thu, 04 Aug 2011 19:08:58 GMT
Server Apache/2.2.3 (Linux/SUSE)
Keep-Alive timeout=15, max=100
Connection Keep-Alive
Transfer-Encoding chunked
Content-Type text/html
Request Headers
Host www.arabdictionary.huji.ac.il
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110614 BTRS35926 Firefox/3.6.18
Accept text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Content-Type application/x-www-form-urlencoded; charset=UTF-8
Content-Length 50
Pragma no-cache
Cache-Control no-cache
Safari data
Request URL:http://www.arabdictionary.huji.ac.il/cgi-bin/arabic_results.pl
Request Headers
Content-Type:application/x-www-form-urlencoded
DNT:1
Origin:file:// <<<<<<<<<<<<<<<<< I think that this is my problem <<<<<<<<<<<<<
User-Agent:Mozilla/5.0 (iPad; U; CPU OS 4_3_3 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8J2 Safari/6533.18.5
Form Data
String:%d4%d4
searchType:byElement
act:dosearch
<<<<<<<<<<< No more data - no Response >>>>>>>>>>>>>>>>>>>>>