Eric Wong wrote:
> Iñaki Baz Castillo 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
> > course
> > the final
Iñaki Baz Castillo 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 values
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 != ppi
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
>
> 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 question
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 th
Iñaki Baz Castillo wrote:
> Hi, in my customized "unicorn" executable I create N forks in master process
> to behave as posix_mq readers.
>
> I added a "at_exit" block just in master process so they are killed when the
> master receives a signal to terminate.
>
> The only issue I'm experimenti
skaar wrote:
> 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-Fo
El Sábado, 9 de Enero de 2010, skaar escribió:
> 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:
>
>
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 p
Hi, in my customized "unicorn" executable I create N forks in master process
to behave as posix_mq readers.
I added a "at_exit" block just in master process so they are killed when the
master receives a signal to terminate.
The only issue I'm experimenting is the fact that they are not killed i
11 matches
Mail list logo
