Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow collect_body/3 to be called just once #43

Closed
josevalim opened this issue Jun 11, 2014 · 9 comments
Closed

Allow collect_body/3 to be called just once #43

josevalim opened this issue Jun 11, 2014 · 9 comments

Comments

@josevalim
Copy link
Member

Today if you call collect_body multiple times, you will get the body the first time and an empty body in the following ones. It would be nice if collect_body/3 instead returned {:error, :already_collected, conn} instead. In order for this to work, we will probably need to store this data or in the connect or in the adapter.

In the adapter is preferable although I am not sure if possible. Does cowboy gives us this information in the new API?

@scrogson, could you please take a look at this? :D After we get this in, we can release v0.5.0 with collect_body/3.

@josevalim josevalim changed the title Allow collect_body to be called just once Allow collect_body/3 to be called just once Jun 11, 2014
@scrogson
Copy link
Contributor

@josevalim I'll look into that. Also, we need to s the non-deprecated functions from cowboy_req for reading the body. Currently we are using stream_body/2 which will be removed in 1.0. The new method for this is cowboy_req:body/2.

https://github.com/extend/cowboy/blob/0.10.0/src/cowboy_req.erl#L99

I'll work on updating this as well.

@ericmj
Copy link
Member

ericmj commented Jun 12, 2014

@scrogson When you are adding support for cowboy 0.10.0 can you make the timeout configurable when collecting the body? Timeouts were added to the new functions for reading the body in cowboy. We really need that feature in hex :)

@scrogson
Copy link
Contributor

After discussing with @josevalim in chat, we've decided to rename this to read_body/2. The signature is very simple:

def read_body(conn, opts \\ []), do: ... end

@ericmj the method will just delegate to cowboy_req:body/2 which will give you full control over the options passed.

Cowboy allows: length, read_length, read_timeout, transfer_decode (fn), and content_decode (fn) as options.

I'm currently working through a test failure and should have this in a PR in the next couple of days.

@ericmj
Copy link
Member

ericmj commented Jun 14, 2014

Should we just pass the options through directly instead of making them part of the adapter interface?

@scrogson
Copy link
Contributor

@ericmj not sure I understand what you mean. I'm passing the options directly into the adapter. As I understand it, we are reading the req_body from the adapters state.

def read_body(%Conn{adapter: {adapter, state}} = conn, opts \\ []) do
  case adapter.read_req_body(state, opts) do
    {:ok, data, state} ->
      {:ok, data, %{conn | adapter: {adapter, state}}}
    {:more, data, state} ->
      {:more, data, %{conn | adapter: {adapter, state}}}
  end
end

@ericmj
Copy link
Member

ericmj commented Jun 14, 2014

@scrogson Plug is supposed to be generic for any adapter. Today we only have cowboy so the issue won't come up. But what if we add another webserver adapter that instead of :read_timeout uses :timeout as the name for the timeout option? We should define and document the options in Plug so that they work for all possible adapters.

@josevalim
Copy link
Member Author

Yeah, I was talking to @scrogson and we have decided exactly that. We are going to use the same names as cowboy, but all supported options should be explicitly documented. We should never say "accepts the same options as cowboy".

@ericmj
Copy link
Member

ericmj commented Jun 14, 2014

@josevalim @scrogson Awesome! 👍

@scrogson
Copy link
Contributor

I've sent a PR for this work in #44

@josevalim and I have discussed that returning {:error, :already_collected, conn} is not really necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants