Opened 13 years ago

Closed 13 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;
        }
    }
}

Change History (1)

comment:1 by Maxim Dounin, 13 years ago

Resolution: → invalid
Status: new → closed

Use of HTTP/1.1 in replies to HTTP/1.0 requests is correct, see ​http://tools.ietf.org/html/rfc2145#section-2.3:

An HTTP server SHOULD send a response version equal to the highest
version for which the server is at least conditionally compliant, and
whose major version is less than or equal to the one received in the
request.

(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.

Note: See TracTickets for help on using tickets.