grantila / fetch-h2

HTTP/1+2 Fetch API client for Node.js
MIT License
336 stars 16 forks source link

Handle all (relevant) Http2Stream events #4

Closed grantila closed 6 years ago

grantila commented 6 years ago

As said in #1, there are Http2Stream events currently not handled. There are different reasons for all of them to not yet having been handled, this is my current thoughts:

Thoughts on this @pranaygp?

grantila commented 6 years ago

Only trailers left. The rest are failure now, they shouldn't happen. Will keep open until trailers are completely implemented.

pranaygp commented 6 years ago

Whoops, sorry for not responding to this earlier.

I agree with the optional argument in the fetch call for trailers. something like handleTrailers might be intuitive? Definitely seems intuitive to me.

I also don't think I completely understand how continue works (will need to read up about this).

With headers is it possible to receive a valid response after receiving a 1xx response? If not, then yeah, rejecting might make sense.

In general, It's likely fine to reject a promise as long as we're providing a user some way to identify which one of these things happened from the error object they receive in .catch

grantila commented 6 years ago

Or onTrailers? Semantics, but still. Perhaps just trailers. We already have onPush.

You're right, it would be very useful to be able to specifically catch these errors, so their constructors must be public. I'll fix that.

Won't close this until all these issues are well defined and documented.

grantila commented 6 years ago

timeout and aborted errors will be handled in #6. Other errors are rare and are pure Error's. Should likely never happen anyway.

pranaygp commented 6 years ago

That makes sense.

I wonder if frameError is a valid error that could be the client's fault, and not the backend?,

pranaygp commented 6 years ago

In any case, yeah, frameError should rejected the promise with an Error. I think the implementation is correct

grantila commented 6 years ago

By the way, @pranaygp, you mentioned the body handling previously, this is changed in #5, so now you can send any string, buffer and readable stream as {body}, and a helper {json} for objects that should be sent as JSON (with application/json automatically set).

pranaygp commented 6 years ago

I noticed that, and was actually just reading the changes

I don't think getStringOrBufferOrReadableStream is a good name though (from the README) How does fetch handle this? Can we just have a single body property in the object that takes a string, or array buffer or stream. And then, the user can just add content-type: application/json to the headers if they want to.

That way we can completely get rid of constructors the user needs to invoke, and stay closer to fetch

On Fri, 3 Nov 2017, 14:46 Gustaf Räntilä, notifications@github.com wrote:

By the way, @pranaygp https://github.com/pranaygp, you mentioned the body handling previously, this is changed in #5 https://github.com/grantila/fetch-h2/issues/5, so now you can send any string, buffer and readable stream as {body}, and a helper {json} for objects that should be sent as JSON (with application/json automatically set).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/grantila/fetch-h2/issues/4#issuecomment-341808049, or mute the thread https://github.com/notifications/unsubscribe-auth/ABtutDRGYyVJ6VtHBLAACd4Ijyn5-tcgks5sy22vgaJpZM4QMeN0 .

grantila commented 6 years ago

That's exactly how it's done now, maybe I was unclear in the docs, I'll update it. I meant that you can assign these types to body directly.

grantila commented 6 years ago

😎 https://github.com/grantila/fetch-h2/commit/bf5028f4000f07add75c3a7b64580603ce873410