6 ms·

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

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 https://github.com/nodejs/undici/issues/1072 [1] https://github.com/denoland/deno/pull/8353 https://github.com/denoland/deno/pull/8353 [2] https://github.com/denoland/deno/issues/4389 https://github.com/denoland/deno/issues/4389

nailer 5y ago
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?).
- inglor 5y ago
  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.
  - andrewl-hn 5y ago
    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.
    - tehbeard 5y ago
      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.
      - Scarbutt 5y ago
        Can you share your setup for talking to SOAP services?
  - true_religion 5y ago
    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.
  - nailer 5y ago
    > 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.
- vanviegen 5y ago
  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.
  - simlevesque 5y ago
    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".
    - nailer 5y ago
      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.
      - andreigheorghe 5y ago
        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.
        deleted 5y ago
        [deleted]
        nailer 5y ago
        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.
  - lucideer 5y ago
- the_duke 5y ago
  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.
  - nailer 5y ago
    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.
inglor 5y ago
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-1025473227 https://github.com/nodejs/node/pull/41749#issuecomment-10254...
tshaddox 5y ago
Is this not what redirect: “manual” is in the MDN fetch docs? https://developer.mozilla.org/en-US/docs/Web/API/fetch https://developer.mozilla.org/en-US/docs/Web/API/fetch
- astrosi 5y ago
  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.
  - tshaddox 5y ago
    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!
    - asiachick 5y ago
      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.
      - tshaddox 5y ago
        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).
        deleted 5y ago
        [deleted]
      - 5y ago

nailer 5y ago

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?).

inglor 5y ago
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.
- andrewl-hn 5y ago
  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.
  - tehbeard 5y ago
    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.
    - Scarbutt 5y ago
      Can you share your setup for talking to SOAP services?
- true_religion 5y ago
  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.
- nailer 5y ago
  > 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.
vanviegen 5y ago
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.
- simlevesque 5y ago
  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".
  - nailer 5y ago
    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.
    - andreigheorghe 5y ago
      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.
      - deleted 5y ago
        [deleted]
      - nailer 5y ago
        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.
- lucideer 5y ago
the_duke 5y ago
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.
- nailer 5y ago
  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.

inglor 5y ago

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-1025473227 https://github.com/nodejs/node/pull/41749#issuecomment-10254...

tshaddox 5y ago

Is this not what redirect: “manual” is in the MDN fetch docs? https://developer.mozilla.org/en-US/docs/Web/API/fetch https://developer.mozilla.org/en-US/docs/Web/API/fetch

astrosi 5y ago
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.
- tshaddox 5y ago
  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!
  - asiachick 5y ago
    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.
    - tshaddox 5y ago
      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).
      - deleted 5y ago
        [deleted]
    - 5y ago