4 ms·
The sad thing is the author owns the 'fetch' standard which could have, like all its predecessors (superagent, axios etc) encoded URL parameters itself, but cho
by nailer 5y ago
The sad thing is the author owns the 'fetch' standard which could have, like all its predecessors (superagent, axios etc) encoded URL parameters itself, but chose to go for a (apparently deliberate) low level approach.
Now the author is pointing out that you need to encode parameters manually. Maybe this is a good case for sane defaults like we had in every HTTP client 10 years ago?
- jaffathecake 5y agoI don't own the fetch standard.
- nailer 5y ago“Is the author and principal advocate of” then? The point still stands.
- jaffathecake 5y agoI am not the author of the fetch standard. It's pretty easy to look this stuff up. I have a few commits to the spec, but I barely show up in the `git blame`. https://github.com/whatwg/fetch/graphs/contributors https://github.com/whatwg/fetch/graphs/contributors I've written articles about fetch in the past, but if I search Google for "fetch API" my stuff doesn't show up in the first few pages at least, so I don't think I really qualify for "principal advocate". Again, it's pretty easy to look this stuff up.
- rendall 5y agoThat's your article? Dude, could you please add a disclaimer that it's insecure no matter what unless the server-side fetch cleans data. You write very authoritatively, and might give naive devs the impression that your solutions are secure enough.
- jaffathecake 5y agoSee the existing thread about this https://news.ycombinator.com/item?id=27698345 https://news.ycombinator.com/item?id=27698345
- rendall 5y agoIt doesn't matter whether the client is a browser or another server. The side that receives the request must always secure the data. You should inform your readers.
- cunthorpe 5y agoI’m glad I can still find funny comments on HN.