5 ms·

I'm not even sure I'd find it desirable for nodejs fetch() to quietly store state somewhere on my server without asking me: I wouldn't know to back that file up

by Aachen 2y ago

I'm not even sure I'd find it desirable for nodejs fetch() to quietly store state somewhere on my server without asking me: I wouldn't know to back that file up, it may be trashed regularly depending on the infrastructure, it could mess with version control by creating a local working directory change, or it might run into an error condition if it is on a read-only filesystem (either crashing or being unable to use this security feature, neither is great). Config file writes are to be expected for user-facing software, but for developers it should error out so they can just choose what it needs to do E.g., "Error: HSTS response received after a redirect from HTTP, but no storage location specified for security states. Use the https:// https:// protocol, specify a file location, or set insecure_ignore_hsts=true." Edit: but it's a very legitimate question?! Just saw you got downvoted, I have no idea why

moralestapia 2y ago
>Just saw you got downvoted, I have no idea why I've noticed a gradual increase in this behavior during the past ... year maybe? I think for a lot of new people, downvoting equates disagreeing, which is not ideal. Although, I also have no idea why someone would disagree with a neutral question like GPs, lol. Hopefully, it's not the beginning of the end for HN as it is a great website.
- iJohnDoe 2y ago
  These types of downvotes also discourage discussions. I’ll upvote a comment when it has been downvoted if it has a constructive discussion thread.
hn_throwaway_99 2y ago
I think the original question "Okay.. does nodejs fetch respect HSTS?" goes into the "not even wrong" bucket, for the reasons you point out. HSTS really only makes sense from a browser perspective (or, rather, a "permanently installed, stateful client" perspective). For an API like fetch it doesn't even make sense as a question IMO.
- moralestapia 2y ago
  >For an API like fetch it doesn't even make sense as a question IMO. Why not?
  - hn_throwaway_99 2y ago
    Because the way HSTS works fundamentally implies a stateful client, and because it was fundamentally created to solve a human problem (i.e. humans entering in URLs directly in the address bar). It really doesn't make sense with a non-stateful client, and it isn't intended for cases where someone isn't manually entering in the URL to hit. E.g. fetch is often loaded in transient situations - it really shouldn't be updating its own config because of responses it gets. Also, based on the other comment I was originally thinking it would be good if fetch would just error out if it gets a redirect from http -> https AND also a Strict-Transport-Security header, but in that case it would still mean it was dependent on the server setting up the STS header, and if they could do that they should just go ahead and get rid of the http -> https redirect in the first place.
    - moralestapia 2y ago
      I agree with you on things like CORS, but HSTS would actually solve the problem stated in this thread quite gracefully. Client fetches http, notices the header, retries https then ... ok no, lol. But I guess it's still of some use to let clients know "this should always happen through https" and make them fail if that's not the case. Edit: yeah I got it, client fetches http, notices the header and then explicitly fails because HSTS is there.
- Aachen 2y ago
  I would say it does make sense as a nice upgrade path for services that don't yet support https but you'd like to switch as soon as they enable it, or if you're forgetful or lazy and didn't type https:// https:// in front of the link you were given or so Whether that's still common enough to warrant the extra complexity in the fetch function is not something I'm qualified to judge

by Aachen 2y ago

moralestapia 2y ago

>Just saw you got downvoted, I have no idea why I've noticed a gradual increase in this behavior during the past ... year maybe? I think for a lot of new people, downvoting equates disagreeing, which is not ideal. Although, I also have no idea why someone would disagree with a neutral question like GPs, lol. Hopefully, it's not the beginning of the end for HN as it is a great website.

iJohnDoe 2y ago
These types of downvotes also discourage discussions. I’ll upvote a comment when it has been downvoted if it has a constructive discussion thread.

hn_throwaway_99 2y ago

I think the original question "Okay.. does nodejs fetch respect HSTS?" goes into the "not even wrong" bucket, for the reasons you point out. HSTS really only makes sense from a browser perspective (or, rather, a "permanently installed, stateful client" perspective). For an API like fetch it doesn't even make sense as a question IMO.

moralestapia 2y ago
>For an API like fetch it doesn't even make sense as a question IMO. Why not?
- hn_throwaway_99 2y ago
  Because the way HSTS works fundamentally implies a stateful client, and because it was fundamentally created to solve a human problem (i.e. humans entering in URLs directly in the address bar). It really doesn't make sense with a non-stateful client, and it isn't intended for cases where someone isn't manually entering in the URL to hit. E.g. fetch is often loaded in transient situations - it really shouldn't be updating its own config because of responses it gets. Also, based on the other comment I was originally thinking it would be good if fetch would just error out if it gets a redirect from http -> https AND also a Strict-Transport-Security header, but in that case it would still mean it was dependent on the server setting up the STS header, and if they could do that they should just go ahead and get rid of the http -> https redirect in the first place.
  - moralestapia 2y ago
    I agree with you on things like CORS, but HSTS would actually solve the problem stated in this thread quite gracefully. Client fetches http, notices the header, retries https then ... ok no, lol. But I guess it's still of some use to let clients know "this should always happen through https" and make them fail if that's not the case. Edit: yeah I got it, client fetches http, notices the header and then explicitly fails because HSTS is there.
Aachen 2y ago
I would say it does make sense as a nice upgrade path for services that don't yet support https but you'd like to switch as soon as they enable it, or if you're forgetful or lazy and didn't type https:// https:// in front of the link you were given or so Whether that's still common enough to warrant the extra complexity in the fetch function is not something I'm qualified to judge