Hacker News Reader

Comment by zebracanevra | Hacker News Reader

Is there any chance to break spec and allow manual redirect handling? the fetch API makes a lot of sense in a browser, but imo this is a pretty crucial feature that undici's implementation lacks. [0]

Deno decided to break spec [1][2] so the following code works fine:

    fetch('https://httpbin.org/status/302', {redirect: 'manual'})
      .then(res => console.log(res.status, res.headers))

In undici this will succeed but with res.status 0 and no headers, as per spec. You aren't allowed to see the content of a redirect, like in a browser.

[0] https://github.com/nodejs/undici/issues/1072 [1] https://github.com/denoland/deno/pull/8353 [2] https://github.com/denoland/deno/issues/4389

View on HN

Yes, this is a place where Node.js will diverge from the spec see discussion on the fetch PR https://github.com/nodejs/node/pull/41749#issuecomment-10254...

Is this not what redirect: “manual” is in the MDN fetch docs?

https://developer.mozilla.org/en-US/docs/Web/API/fetch

In that in the browser you are able to see that you have gotten a 301/302 response but can't see where the redirect would have sent you.

Oh right, because they don’t want cross-site scripts to be able to see redirected URLs since they could contain secrets. I wish we could completely do away with cross-site scripts and just have nice things!

Yea, so instead it would just encourage more 3rd party libraries doing random things on your site. This is what happens in native. Instead of embedding an ad in an iframe and isolating its damage you embed your ad service's library in your code and it spies on way more activity than it ever could otherwise.

I would also be okay (ish) with explicitly isolated third-party code execution, like your example of an iframe to a different domain. I'm pretty sure that should already be the case with iframes, in fact (you obviously shouldn't be able to embed an iframe to facebook.com on your website and then use your website's JavaScript to inspect the DOM on that facebook.com iframe).

It's pretty funny that such an RPC framework as the browser exists that gives the end user a genuinely decent sandbox, yet all it receives is criticism for its flaws. People will then happily install a screen dimmer or "productivity" tool with superuser privileges from a completely untrusted source.

A better idea would be to replace / improve the fetch spec. Handle redirects, set JSON as the default request content type, encode URI components for users, decode response bodies with JSON headers as JS objects, etc.

Right now most developers either write their own library to do these things on top of fetch or another HTTP client or use a third party library from npm.

A new standard would allow us to make http requests out of the box comparable to high level HTTP clients like superagent, axios etc. that have been in use for the last decade, since before fetch was conceived, with whatever benefits fetch provides (I think it's cancellable now?).

A new standard would need buy-in from browsers to actually be a standard. Browsers likely don't have a lot of incentive to make spec changes only Node is interested in (like making the whole spec more complicated from their point of view because of Node's (or Deno's) different security model).

The level of collaboration and good-faith we've been getting from spec bodies like WHATWG is very high as it is and we really don't want to push or abuse it.

Does it have to be a buy-in, though? You could agree on server-specific extensions to fetch and codify them in the same spec (so it doesn't get lost otherwise). Browser vendors wouldn't need to implement it but they will still keep an eye on it when working on future browser apis.

Codifying the redirect behaviour for server/"trusted" envs makes some sense with Deno/node doing the same thing. I'm not versed enough in the standards orginazation politics to say if that's viable though.

The rest of your "improvements" aren't that. They're opinions, opinions laser focused on a JSON centric api.

I'm sorry to say this, but not all of the web is one big JSON blob.

Some of us have to talk to SOAP (xml) services.

Sometimes it's weird rpc stuff with protobuf.

Or even just pulling down raw binary data and feeding that through an API/library that wasn't built for web streams.

Honestly, the amount of code you need to add over the top of a primitive like the Fetch API to get what you wanted (bar the redirect change) is trivial and minimal.

Can you share your setup for talking to SOAP services?

It would be useful for trusted browser extensions too, as well as probably Electon apps as well.

I don’t know if chrome apps are still in existence, but if they are the “server side” fetch spec could apply to them too.

> Browsers likely don't have a lot of incentive to make spec changes only Node is interested in

All the existing HTTP clients discussed in the previous post also run in the browser.

Why is this being down voted? This comment seems to be making a reasonable case.

In case you disagree, you may want to reply why instead of down voting.

Because fetch just landed in Node.js, making it a standard present in every context after like 5 years and he want to change the standard now.

Edit: also, you are being downvoted because the etiquette on HN are that you don't ask "why was X downvoted".

As mentioned existing HTTP clients had this behaviour back in 2012, the designers of fetch chose to ignore these cowpaths in favour of a more minimal implementation requiring the use of third party HTTP clients in both browsers and node, simply to have reasonable defaults and not repeat oneself, for the foreseeable future.

the value the js community gets from `fetch` being a unified standard is far, far greater than the benefit you as a developer would get from not having to add 15 extra LOC around `fetch`, that you'll probably hide behind a `fetchJSON` function anyway.

Point is everyone had a slightly different 150 LOC or a library to achieve essentially the same thing.

We could have stuck with ‘if index is not equal to minus one’ but we have array includes now for the same reason.

I didn't downvote, but my guess is its primarily a kneejerk reaction to the following line:

> set JSON as the default request content type

or something similarly subjective.

Downvoting is going a bit too far, but bundling a few individual opinions on defaults alongside broadly accepted (implemented in both Node & Deno after much discussion) features seems... presumptuous.

None of the things you mentioned are reasonable default behaviours, and are easy one liners. You don't need a library for any of that.

Thanks for your opinion, however as mentioned, or as you’ll be aware if you’ve used JavaScript, these are well worn cow paths that have been default in the most popular HTTP clients for a decade now.

Reply on news.ycombinator.com