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!
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.
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.
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.
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.
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!