Eric,
think I came across an issue with the parser in unicorn, with a request
(due to 2 layers of nginx proxying) coming across with both a
X_FORWARDED_PROTO and a X-Forwarded-Proto header. From the socket (in
HttpRequest) - we get:
X_FORWARDED_PROTO: http
X-Forwarded-Proto: https
which is
El Sábado, 9 de Enero de 2010, Eric Wong escribió:
The worker_loop just compares Process.ppid with the original ppid it
was started with. They wakeup from IO.select() every timeout/2 seconds
to check for original_ppid != ppid if the server is idle.
Thanks, I was expecting exactly that as the
The Rack (and CGI) specs require that '-' be replaced with '_' for
HTTP header names, so Unicorn is doing the correct thing and treating
it as the same header.
but should it aggregate the values?
Even though '_' appears to be allowed in header names by rfc 2616, it's
use is questionable
El Domingo, 10 de Enero de 2010, skaar escribió:
The Rack (and CGI) specs require that '-' be replaced with '_' for
HTTP header names, so Unicorn is doing the correct thing and treating
it as the same header.
but should it aggregate the values?
Hi, review my other response in this
El Sábado, 9 de Enero de 2010, Iñaki Baz Castillo escribió:
El Sábado, 9 de Enero de 2010, Eric Wong escribió:
The worker_loop just compares Process.ppid with the original ppid it
was started with. They wakeup from IO.select() every timeout/2 seconds
to check for original_ppid != ppid if
Iñaki Baz Castillo i...@aliax.net wrote:
El Domingo, 10 de Enero de 2010, skaar escribió:
The Rack (and CGI) specs require that '-' be replaced with '_' for
HTTP header names, so Unicorn is doing the correct thing and treating
it as the same header.
but should it aggregate the
Eric Wong normalper...@yhbt.net wrote:
Iñaki Baz Castillo i...@aliax.net wrote:
In your case it seems valid for me (just an opinnion) as
HTTP_X_FORWARDED_PROTO: http,https could mean that the request has been
sent
using HTTPS and an intermediary proxy has forwarded it using HTTP. Of
