Reject requests when containing headers `content-length` and
`transfer-encoding` at the same time.

That's not allowed by RFC 9112 and that could lead to
potential security attacks.

This is an extract of the RFC:

> A server MAY reject a request that contains both Content-Length and
> Transfer-Encoding or process such a request in accordance with the
> Transfer-Encoding alone. Regardless, the server MUST close the
> connection after responding to such a request to avoid the potential
> attacks.

> A server or client that receives an HTTP/1.0 message containing
> a Transfer-Encoding header field MUST treat the message as if the
> framing is faulty, even if a Content-Length is present, and close the
> connection after processing the message. The message sender might have
> retained a portion of the message, in buffer, that could be
> misinterpreted by further use of the connection.

The following request would lead to this scenario:

```
POST / HTTP/1.1
Host: a.com
Transfer-Encoding: chunked
Content-Length: 0
Content-Type: application/x-"##-form-urlencoded
14
id=1'or sleep(1);###
0
```

With these changes, when this kind of request is received the connection is
closed and an error 400 is returned.

This scenario can be tested by using the following process:

1. run a wsgi server either:
    - by using the wsgi sample in official examples
      (http://eventlet.net/doc/examples.html#wsgi-server)
    - or by using my previous patch
      (eventlet#825) that allow
      you to run wsgi server from the command line (`$
      eventlet_wsgi_example`)
2. send the following HTTP request to the running server:
```
curl -d "param1=value1&param2=value2" -X POST -H 'Transfer-Encoding:
chunked' -H 'Content-Length: 0' --http1.1 http://0.0.0.0:8090 -i
```

The previous curl command display returned headers and status code.
You can observe that now, with these changes, bad requests are rejected.

This security issue was originally discovered by Keran Mu
([email protected]) and Jianjun Chen
([email protected]), from Tsinghua University and
Zhongguancun Laboratory

Thanks to them for undisclosing this security problem.

Reject requests when containing headers `content-length` and
`transfer-encoding` at the same time.

That's not allowed by RFC 9112 and that could lead to
potential security attacks.

This is an extract of the RFC:

> A server MAY reject a request that contains both Content-Length and
> Transfer-Encoding or process such a request in accordance with the
> Transfer-Encoding alone. Regardless, the server MUST close the
> connection after responding to such a request to avoid the potential
> attacks.

> A server or client that receives an HTTP/1.0 message containing
> a Transfer-Encoding header field MUST treat the message as if the
> framing is faulty, even if a Content-Length is present, and close the
> connection after processing the message. The message sender might have
> retained a portion of the message, in buffer, that could be
> misinterpreted by further use of the connection.

The following request would lead to this scenario:

```
POST / HTTP/1.1
Host: a.com
Transfer-Encoding: chunked
Content-Length: 0
Content-Type: application/x-"##-form-urlencoded
14
id=1'or sleep(1);###
0
```

With these changes, when this kind of request is received the connection is
closed and an error 400 is returned.

This scenario can be tested by using the following process:

1. run a wsgi server either:
    - by using the wsgi sample in official examples
      (http://eventlet.net/doc/examples.html#wsgi-server)
    - or by using my previous patch
      (eventlet#825) that allow
      you to run wsgi server from the command line (`$
      eventlet_wsgi_example`)
2. send the following HTTP request to the running server:
```
curl -d "param1=value1&param2=value2" -X POST -H 'Transfer-Encoding:
chunked' -H 'Content-Length: 0' --http1.1 http://0.0.0.0:8090 -i
```

The previous curl command display returned headers and status code.
You can observe that now, with these changes, bad requests are rejected.

This security issue was originally discovered by Keran Mu
([email protected]) and Jianjun Chen
([email protected]), from Tsinghua University and
Zhongguancun Laboratory

Thanks to them for raising our attention about this security problem.

Reject requests which contains headers `content-length` and
`transfer-encoding` at the same time.

That's not allowed by RFC 9112 and that could lead to
potential security attacks.

This is an extract of the RFC:

> A server MAY reject a request that contains both Content-Length and
> Transfer-Encoding or process such a request in accordance with the
> Transfer-Encoding alone. Regardless, the server MUST close the
> connection after responding to such a request to avoid the potential
> attacks.

> A server or client that receives an HTTP/1.0 message containing
> a Transfer-Encoding header field MUST treat the message as if the
> framing is faulty, even if a Content-Length is present, and close the
> connection after processing the message. The message sender might have
> retained a portion of the message, in buffer, that could be
> misinterpreted by further use of the connection.

The following request would lead to this scenario:

```
POST / HTTP/1.1
Host: a.com
Transfer-Encoding: chunked
Content-Length: 0
Content-Type: application/x-"##-form-urlencoded
14
id=1'or sleep(1);###
0
```

With these changes, when this kind of request is received the connection is
closed and an error 400 is returned.

This scenario can be tested by using the following process:

1. run a wsgi server either:
    - by using the wsgi sample in official examples
      (http://eventlet.net/doc/examples.html#wsgi-server)
    - or by using my previous patch
      (eventlet#825) that allow
      you to run wsgi server from the command line (`$
      eventlet_wsgi_example`)
2. send the following HTTP request to the running server:
```
curl -d "param1=value1&param2=value2" -X POST -H 'Transfer-Encoding:
chunked' -H 'Content-Length: 0' --http1.1 http://0.0.0.0:8090 -i
```

The previous curl command display returned headers and status code.
You can observe that now, with these changes, bad requests are rejected.

This security issue was originally discovered by Keran Mu
([email protected]) and Jianjun Chen
([email protected]), from Tsinghua University and
Zhongguancun Laboratory

Thanks to them for raising our attention about this security problem.

Reject requests which contains headers `content-length` and
`transfer-encoding` at the same time.

That's not allowed by RFC 9112 and that could lead to
potential security attacks.

https://www.rfc-editor.org/rfc/rfc9112#section-6.1-15

This is an extract of the RFC:

> A server MAY reject a request that contains both Content-Length and
> Transfer-Encoding or process such a request in accordance with the
> Transfer-Encoding alone. Regardless, the server MUST close the
> connection after responding to such a request to avoid the potential
> attacks.

> A server or client that receives an HTTP/1.0 message containing
> a Transfer-Encoding header field MUST treat the message as if the
> framing is faulty, even if a Content-Length is present, and close the
> connection after processing the message. The message sender might have
> retained a portion of the message, in buffer, that could be
> misinterpreted by further use of the connection.

The following request would lead to this scenario:

```
POST / HTTP/1.1
Host: a.com
Transfer-Encoding: chunked
Content-Length: 0
Content-Type: application/x-"##-form-urlencoded
14
id=1'or sleep(1);###
0
```

With these changes, when this kind of request is received the connection is
closed and an error 400 is returned.

This scenario can be tested by using the following process:

1. run a wsgi server either:
    - by using the wsgi sample in official examples
      (http://eventlet.net/doc/examples.html#wsgi-server)
    - or by using my previous patch
      (eventlet#825) that allow
      you to run wsgi server from the command line (`$
      eventlet_wsgi_example`)
2. send the following HTTP request to the running server:
```
curl -d "param1=value1&param2=value2" -X POST -H 'Transfer-Encoding:
chunked' -H 'Content-Length: 0' --http1.1 http://0.0.0.0:8090 -i
```

The previous curl command display returned headers and status code.
You can observe that now, with these changes, bad requests are rejected.

This security issue was originally discovered by Keran Mu
([email protected]) and Jianjun Chen
([email protected]), from Tsinghua University and
Zhongguancun Laboratory

Thanks to them for raising our attention about this security problem.