
Show HN: Lint for HTTP - vfaronov
https://github.com/vfaronov/httpolice
======
deathanatos
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!

~~~
vfaronov
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.

------
voltagex_
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](http://fiddler.wikidot.com/saz-
files)

2: [http://www.telerik.com/fiddler](http://www.telerik.com/fiddler)

~~~
NKCSS
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.

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

~~~
vfaronov
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.

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

------
tedmiston
This is great.

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

~~~
vfaronov
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/](http://python-eve.org/)

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

~~~
vfaronov
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.

------
nstj
Spectacular project - nice work.

