4 ms·

> Servers can now send HSTS along with the initial HTTP-to-HTTPS redirection response > Node.js's built-in fetch happily and quietly followed those redirects t

> Servers can now send HSTS along with the initial HTTP-to-HTTPS redirection response > Node.js's built-in fetch happily and quietly followed those redirects to the HTTPS endpoint. Okay.. does nodejs fetch respect HSTS?

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
NewJazz 2y ago
I'm not aware of any general programming language http clients that honor HSTS.
- pzmarzly 2y ago
  libcurl supports HSTS, but the client has to specify a file where the state should be stored https://curl.se/docs/hsts.html https://curl.se/docs/hsts.html Many languages/libraries use libcurl in some shape or form, but whether they set up an on-disk HSTS store or not - I don't know either.
g15jv2dp 2y ago
How would that even work? It's up to the developer to consider the response and act correctly on it.
- Aachen 2y ago
  Same way as TLS session resumption can be handled by libraries without you having to touch it, or perhaps requiring you to specify a storage file and taking it from there
- andersa 2y ago
  Just do it like a web browser - when you install Chrome it comes with a list of many tens of thousands of domains that had HSTS set when GoogleBot visited it.
- akira2501 2y ago
  So if you occasionally forget and use http when you meant https and are worried about the consequences of that, you should just implement your own HSTS checking layer? Why not just implement your own fetch wrapper that throws if it's not an https connection?
  - g15jv2dp 2y ago
    > So if you occasionally forget and use http when you meant https and are worried about the consequences of that, you should just implement your own HSTS checking layer? Or use a library to do it. The core fetch functionality shouldn't have to deal with HSTS. There may be legitimate reasons to fetch over HTTP even after you received an HSTS header - for testing purposes, for example. > Why not just implement your own fetch wrapper that throws if it's not an https connection? That's the developer dealing with HSTS.

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

NewJazz 2y ago

I'm not aware of any general programming language http clients that honor HSTS.

pzmarzly 2y ago
libcurl supports HSTS, but the client has to specify a file where the state should be stored https://curl.se/docs/hsts.html https://curl.se/docs/hsts.html Many languages/libraries use libcurl in some shape or form, but whether they set up an on-disk HSTS store or not - I don't know either.

g15jv2dp 2y ago

How would that even work? It's up to the developer to consider the response and act correctly on it.

Aachen 2y ago
Same way as TLS session resumption can be handled by libraries without you having to touch it, or perhaps requiring you to specify a storage file and taking it from there
andersa 2y ago
Just do it like a web browser - when you install Chrome it comes with a list of many tens of thousands of domains that had HSTS set when GoogleBot visited it.
akira2501 2y ago
So if you occasionally forget and use http when you meant https and are worried about the consequences of that, you should just implement your own HSTS checking layer? Why not just implement your own fetch wrapper that throws if it's not an https connection?
- g15jv2dp 2y ago
  > So if you occasionally forget and use http when you meant https and are worried about the consequences of that, you should just implement your own HSTS checking layer? Or use a library to do it. The core fetch functionality shouldn't have to deal with HSTS. There may be legitimate reasons to fetch over HTTP even after you received an HSTS header - for testing purposes, for example. > Why not just implement your own fetch wrapper that throws if it's not an https connection? That's the developer dealing with HSTS.