Opened 8 months ago

Closed 8 months ago

#1728 closed defect (duplicate)

Parsing HTTP request is wrong

Reported by: akayunov@… Owned by:
Priority: minor Milestone:
Component: other Version: 1.15.x
Keywords: Cc:
uname -a:
nginx -V: 1.15.7

Description

I do following request to nginx server:

curl  -vv -k -X GET 'https://nginx.org/ H'
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying 95.211.80.227...
* TCP_NODELAY set
* Connected to nginx.org (95.211.80.227) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=nginx.org
*  start date: Feb 14 15:23:55 2019 GMT
*  expire date: May 15 15:23:55 2019 GMT
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> GET / H HTTP/1.1
> Host: nginx.org
> User-Agent: curl/7.52.1
> Accept: */*
> 
< HTTP/1.1 400 Bad Request
< Server: nginx/1.15.7
< Date: Tue, 19 Feb 2019 13:47:39 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 157
< Connection: close

and as you can see get 400 Bad request. You can answer me that I get this response because I don't use url encoding but I say to you that you parse first line of request in wrong way. You try to find first combination of space and letter "H" instead of find method uri and protocol version.
Just think about it, you change one letter in request and get different response! If I change "H" by "R" for example I get 404:

curl  -vv -k -X GET 'https://nginx.org/wqe/ R'
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying 95.211.80.227...
* TCP_NODELAY set
* Connected to nginx.org (95.211.80.227) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=nginx.org
*  start date: Feb 14 15:23:55 2019 GMT
*  expire date: May 15 15:23:55 2019 GMT
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> GET /wqe/ R HTTP/1.1
> Host: nginx.org
> User-Agent: curl/7.52.1
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Server: nginx/1.15.7
< Date: Tue, 19 Feb 2019 14:00:45 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 4267
< Connection: keep-alive
< Keep-Alive: timeout=15
< ETag: "5c339c5d-10ab"

It's not because I do wrong request It's because you do wrong parsing althoritm.

Change History (1)

comment:1 Changed 8 months ago by vbart

  • Resolution set to duplicate
  • Status changed from new to closed

Actually both requests are invalid. You must encode the request URI.
As of inconsistent behaviour, there's already ticket #196.

Note: See TracTickets for help on using tickets.