unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / Atom feed
* env reuse and hijack
@ 2017-11-29  0:13 Sam Saffron
  2017-11-29  1:03 ` Eric Wong
  0 siblings, 1 reply; 4+ messages in thread
From: Sam Saffron @ 2017-11-29  0:13 UTC (permalink / raw)
  To: unicorn-public

I was reading through unicorn today and noticed that it uses
`HttpParser_clear` to clear up env between requests as opposed to
allocating a new `env` object.

This is generally fine, but if you hijack a request you may want to
still look at env after this is done leading to situations where you
are looking at the wrong env by the time you are dealing with the
hijacked request

I guess I have 2 questions

1. Should Rack specify that env must be "re-initialized" if for any
reason a request is hijacked?

2. Should unicorn allow you to opt for env "recycle" via a rack key?

I don't really have the answers here, my simplest course of action is
simple to clone all the key/value pairs in env on to a new hash when I
hijack, but it feels wasteful.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-29  0:13 env reuse and hijack Sam Saffron
2017-11-29  1:03 ` Eric Wong
2017-12-05  1:53   ` Eric Wong
2017-12-16  1:49     ` [PATCH] avoid reusing env on hijack Eric Wong

unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help

Archives are clonable:
	git clone --mirror https://bogomips.org/unicorn-public
	git clone --mirror http://ou63pmih66umazou.onion/unicorn-public

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn
	nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.unicorn

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox