Opened 12 years ago
Closed 12 years ago
#112 closed defect (invalid)
Nginx does not obey client http version
| Reported by: | Jiri Lunacek | Owned by: | somebody |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | nginx-core | Version: | 1.0.x |
| Keywords: | Cc: | ||
| uname -a: | Linux test1.hosting90.cz 2.6.18-274.3.1.el5 #1 SMP Tue Sep 6 20:13:52 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.0.12
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-50) TLS SNI support disabled configure arguments: --prefix=/etc/nginx/ --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-cc-opt='-O2 -g -m64 -mtune=generic' |
||
Description
Hi.
I have discovered that nginx 1.0.12 does not obey client HTTP protocol version and sends a reply always in version 1.1.
In our situation this caused a proxy sending out stripe headers with the reply to client.
Client -> nginx proxy http/1.0 -> nginx server http/1.1 striped reply -> nginx proxy http/1.0 expecting only data but receiving also stripe headers.
This is a communication log with nginx 1.0.12 in default configuration:
GET / HTTP/1.0
HTTP/1.1 200 OK
Server: nginx/1.0.12
Date: Mon, 20 Feb 2012 13:36:45 GMT
Content-Type: text/html
Content-Length: 151
Last-Modified: Mon, 06 Feb 2012 16:00:29 GMT
Connection: close
Accept-Ranges: bytes
<html>
<head>
<title>Welcome to nginx!</title>
</head>
<body bgcolor="white" text="black">
<center><h1>Welcome to nginx!</h1></center>
</body>
</html>
Nginx config:
user nginx;
worker_processes 1;
server {
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
server {
listen 80;
server_name _;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
}
Note:
See TracTickets
for help on using tickets.
Use of HTTP/1.1 in replies to HTTP/1.0 requests is correct, see http://tools.ietf.org/html/rfc2145#section-2.3:
(Note that use of HTTP/1.1 in a response line doesn't mean that HTTP/1.1 specific features which can't be understood by a HTTP/1.0 client are used in the response. See RFC2616 for details.)
That is, use of HTTP/1.1 in a response line by itself is certainly not a bug, it's standard complain behaviour. From your explanation it's not clear which problems this causes in your case (if any). If it does indeed cause problems, you may want to ask mailing list for help with more details.