Custom Query (2311 matches)
Results (52 - 54 of 2311)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #2566 | invalid | mail_proxy_module proxy_smtp_auth not respecting AUTH capabilities of backend | ||
| Description |
When nginx is proxying smtp auth it always uses "AUTH PLAIN <base64-encoded-username-and-passsword>" when trying to authenticate, despite the backend only offers "AUTH LOGIN". This is the traffic between nginx and the backend: 220 exchange-backend Microsoft ESMTP MAIL Service ready at Mon, 20 Nov 2023 12:15:10 +0100 EHLO localhost 250-exchange-backend Hello [10.0.0.11] 250-SIZE 37748736 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-AUTH LOGIN 250-8BITMIME 250-BINARYMIME 250-CHUNKING 250 SMTPUTF8 AUTH PLAIN dGVzdAAxMjM0Cg== 504 5.7.4 Unrecognized authentication type |
|||
| #2565 | invalid | ویکی | ||
| Description |
Http/vike:domain formatting |
|||
| #2564 | invalid | nginx returns 501 when 400 is expected | ||
| Description |
nginx seems to be exhibiting unexpected behavior when sending an invalid value for the Transfer-Encoding header. I've been using the nginx docker container to test with locally: docker run -p 8080:80 nginx The following curl request results in an HTTP 501: curl -I -X POST -H "Transfer-Encoding: invalid" localhost:8080 According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding there are only 4 valid values for the Transfer-Encoding header. If a client sends an invalid value, I'd expect the server to respond with an HTTP 400. nginx responds with an HTTP 501. |
|||
