Show HN: Lint for HTTP | Hacker News Reader

Show HN: Lint for HTTP

github.com

138 pointsvfaronov12 comments

This is beautiful! I need integrate this into our pre-production environments like yesterday! I have long wanted something like this; some of our internal APIs abuse HTTP response codes and one of our mobile app sends an invalid User-Agent string. Pointing folks at the relevant standards passages and trying to explain what they're doing wrong, and why it affects other real-world applications seems to get acknowledgement, but often no change because by the time we've caught it, it is out in the wild.

The report format is beautiful too — I love that hovering highlights the relevant portions of the request, and thank you for the explain link; I loathe linters that offer no rationale.

Also, I love that the example taught me something too; I did not know some of these.

Also, very interesting that one of your examples is the Pragma header. I did not know that it was defined for requests only (and your explain link explains its rationale clearly enough that I now agree with it). I just implemented an OAuth client, and that standard requires it on responses:

> The authorization server MUST include the HTTP "Cache-Control" response header field [RFC2616] with a value of "no-store" in any response containing tokens, credentials, or other sensitive information, as well as the "Pragma" response header field [RFC2616] with a value of "no-cache".

The very RFC it cites even notes that this is unspecified!

Thank you, I'm very glad to read this.

> I need integrate this into our pre-production environments like yesterday!

Please feel free to share your experiences. The integration story here clearly needs more work, and it would be quite helpful to know where to focus.

I wonder how hard it'd be to add support for SAZ files? [1]

As a Windows web dev, Fiddler [2] is pretty much invaluable, especially if I'm dealing with black-box services (I'm looking at you, Cisco).

1: http://fiddler.wikidot.com/saz-files

2: http://www.telerik.com/fiddler

Maybe kick telerik to support .har in Fiddler? Seems like it's the de-facto standard that browsers implement; would be good to have one thing that works for all.

Aha! Thanks for that. I checked and it seems to support "export" of HAR 1.1 and 1.2.

Right. I just checked and HAR 1.2 seems to work pretty well. A small nuisance is that Fiddler synthesizes bodies with debug information on CONNECT requests and responses, but I'll work around that in the next release.

But experience with Web browsers shows that there's a lot that can go wrong with HAR, so if you notice any other problems, feel free to submit an issue on GitHub so I can look into it.

The inclusion of the explanations is fantastic. This is a wonderful tool, and a very useful one.

This is great.

I'm curious to know if anyone has tested it against popular web frameworks yet?

I ran some of the tests for a few of Django's more popular API and CMS frameworks, instrumented with HTTPolice. I found a few minor bugs, but nothing interesting enough to report. Like, one of them responds to an OPTIONS request with 200 (OK) but forgets to list OPTIONS itself in the Allow header -- cosmetic stuff like that.

I hope to try it on Eve [1] soon-ish.

[1] http://python-eve.org/

Excellent. Any chance you're referring to Django Rest Framework?

Yes, DRF was one of those. But I don't remember whether I ran the whole test suite or only some subset of it that I could (quickly) get to run at all :) My goal was to get a sense of what it would look like on a realistic project, not so much to test DRF itself.

Spectacular project - nice work.

Reply on news.ycombinator.com