1
0
Fork 0
mirror of https://github.com/puma/puma.git synced 2022-11-09 13:48:40 -05:00
Commit graph

17 commits

Author SHA1 Message Date
Evan Phoenix
4ea35190ec Add experimental tcp mode (aka lopez express mode) 2013-08-07 16:39:08 -07:00
Evan Phoenix
dcf96b79a6 Handle all read exceptions properly. Fixes #252 2013-06-01 14:20:45 -07:00
Evan Phoenix
daa76a1e90 Add support for the rack hijack protocol 2013-02-05 22:39:16 -08:00
Evan Phoenix
faf7f9916c Merge branch 'minissl' into just-dash-w
Conflicts:
	ext/puma_http11/puma_http11.c
	lib/puma/cli.rb
	lib/puma/server.rb
2012-09-10 08:41:43 -07:00
Evan Phoenix
e9a0b5e615 If trying to stop running, don't do the fast check 2012-09-09 19:51:36 -07:00
Evan Phoenix
111cc1da74 Merge branch 'master' into just-dash-w
Conflicts:
	lib/puma/cli.rb
2012-09-08 23:05:36 -07:00
Evan Phoenix
bd5d824ce5 Write 400 on HTTP parse error. Fixes #142 2012-09-05 22:09:42 -07:00
Evan Phoenix
f38678f2d7 Handle SSL eof and nonblocking 2012-08-22 22:34:10 -07:00
Evan Phoenix
e8d7979c36 Merge branch 'master' into just-dash-w
Conflicts:
	lib/puma/cli.rb
	lib/puma/server.rb
2012-08-10 22:47:17 -07:00
Evan Phoenix
652cf29391 Cleanup the JRuby specific fix 2012-08-10 19:36:01 -07:00
Evan Phoenix
b9388a6074 Optimize for another immediate request on a KA connection 2012-08-10 17:02:30 -07:00
Evan Phoenix
70bbef66cf Work around JRuby buffering the request inside #accept 2012-08-09 16:54:55 -07:00
Evan Phoenix
bfcd20054e Ignore sockets that are already closed 2012-07-24 17:24:44 -07:00
Evan Phoenix
a3aefc1c51 Don't accidentally replay requests over and over
Client#reset uses the presence of @buffer to detect if there is a
partial next request available. Thusly we have to be sure to nil it out
after we use @buffer otherwise we'll accidentally replay the request
over and over again.
2012-07-24 10:59:09 -07:00
Evan Phoenix
44c8c1ab50 Some minor cleanup 2012-07-23 17:00:53 -07:00
Evan Phoenix
5f2b673ec9 Speed up good, eager clients 2012-07-23 14:29:33 -07:00
Evan Phoenix
6777c771d8 Add separate IO reactor to defeat slow clients
Previously, the app thread would be in charge of reading the request
directly from the client. This resulted in a set of slow clients being
able to completely starve the app thread pool and prevent any further
connections from being handled.

This new organization uses a seperate reactor thread that is in charge
of responding when a client has more data, buffering the data and
attempting to parse the data. When the data represents a fully realized
request, only then is it handed to the app thread pool. This means we
trust apps to not starve the pool, but don't trust clients.
2012-07-23 10:26:52 -07:00