Rack: Expect / Continue not supported by Rack

[rkh]

Tried to implement a simple app imitating S3, but failed at that point.

[raggi]

Confirm. This would require a real in-request protocol, and thus probably object request/response contexts (or some re-call process, but the latter sounds horrible).

[spastorino]

@raggi couldn't servers implement this?

I'd expect to see in Rack the request twice. First only with the headers and in the app you could return a 417 and then instead of just receiving the body I'd make servers to send both things headers and the body.

[raggi]

They could iff there was some magic environment variable to describe the continuation.

I could imagine the protocol looking something like this:

env = usual_garbage
env['rack.request_id'] = request_id
s, h, b = app.call(env)
if s == 100
  write_expect(s,h,b)
end
env['rack.continue'] = env['rack.request_id']
s, h, b = redispatch(env)
... etc

Not quite right above, but I think the principle works.

[lukeasrodgers]

@raggi I've written rack middleware that implements this just fine with Unicorn. See https://github.com/defunkt/unicorn/blob/ec8c095b9f6081ec1462db6c4392ab181bd6790e/lib/unicorn/http_server.rb#L567-586

[raggi]

@lukeasrodgers seems ok, but this isn't so easy with concurrent servers, as you can't use a single piece of global state to identify the client that generated the original request.

[jeremyevans]

As the Unicorn approach shows, rack supports Expect/Continue fine, it just requires servers to call back into Rack after the 100 response is sent to the client. With Unicorn's approach, the same environment is reused, just the HTTP_EXPECT entry is deleted, which should allow for state handling via the environment. The first request can set the state in the request environment, which will be preserved when the second request is made.

So this doesn't appear to be a rack issue, it appears to be a server issue. I recommend other servers handle the issue similar to how Unicorn handles it.

[raggi]

Sorry for the flyby comment but maybe this should get added to SPEC?

On Wed, Jan 22, 2020, 3:46 PM Jeremy Evans [e-mail] wrote:

Closed #629 https://github.com/rack/rack/issues/629.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rack/rack/issues/629?email_source=notifications&email_token=AAAACXB3ISLLMZ7HHNVDDMLQ7DLERA5CNFSM4AKIG2G2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOWESTIOY#event-2972005435,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAACXHFTXSCQ7ED2QXM5STQ7DLERANCNFSM4AKIG2GQ
.

[jeremyevans]

We could probably add something to SPEC, but I don't think we could enforce this with Lint, since Lint does not address this behavior.

[ioquatix]

@raggi pleasd make a PR if you have some concrete ideas.