What should we do if a launch handler reads POST data from a request but doesn't handle the launch?

[fallaciousreasoning]

This is based on #15.

I have two main thoughts here: a) As the launch event handler is likely to have an aggressive timeout, reading the request body is probably not a good idea - Maybe we should block reading the body? b) However we handle this, it should match up exactly with whatever fetch does.

@raymeskhoury for input.

[raymeskhoury]

@jakearchibald could you explain your concerns here a bit more so we can make sure we address the issue properly?

[jakearchibald]

a) As the launch event handler is likely to have an aggressive timeout, reading the request body is probably not a good idea - Maybe we should block reading the body?

Wouldn't that prevent the share target use-case?

could you explain your concerns here a bit more

You can't typically read a request/response body twice. If the developer reads it in the launch event, how will the browser be able to read it when it makes the actual request?

[fallaciousreasoning]

Wouldn't that prevent the share target use-case?

I think there's often enough information in the query string to decide what to do. But yeah, you're right, blocking reading probably isn't a great solution :/

[raymeskhoury]

You can't typically read a request/response body twice. If the developer reads it in the launch event, how will the browser be able to read it when it makes the actual request?

@jakearchibald interesting.

What happens in a fetch handler if you read the request body and then request() it? I guess the same thing could happen?

[raymeskhoury]

Oh I just noticed your answer to the same question in https://github.com/WICG/sw-launch/issues/15. It seems like it should work ok. In that case perhaps we can close this?