Using url_for is useful if httpbin is served under a prefix path. For
example, we can serve httpbin under http://example.org/httpbin.
Previously, we have to replace all hard coded paths, which produces
many diffs, and it makes hard to upgrade httpbin from source. This
commit uses url_for to resolve correct path even if prefix path is
used. For digest auth, we have to prepend request.script_root to
request.path to pass authentication.
`gunicorn==18.0` had previously been listed in requirements.txt, but I
removed it in commit d851a7e2a1 for
compatibility with the new httpbin.org hosting platform.
gunicorn 19.2 has (finally) been released, and this version will work
correctly for httpbin.org. This change adds `gunicorn==19.2` back to
requirements.txt.
This may also fix problems deploying to Heroku reported by @sigmavirus24,
which may have been caused by the requirement change in
d851a7e2a1.
There's no standard for the headers added by a reverse proxy when it handles
an https incoming request. Some proxies add `X-Forwarded-Proto` but others add
`X-Forwarded-Protocol` or `X-Forwarded-Ssl`. This change lets httpbin work with
reverse proxies use any of these headers. It also instructs httpbin to ignore
those headers because they're added by a proxy.
Fixes#207. @sigmavirus24 was correct, Heroku uses `X-Forwarded-Proto` but the
Runscope hosting platform uses `X-Forwarded-Protocol`.
At Runscope we use Bugsnag to track application exceptions. This commit allows
you to use Bugsnag to track httpbin exceptions. If you want to do this, you'll
need to set the environment variable BUGSNAG_API_KEY and optionally set the
variable BUGSNAG_RELEASE_STAGE. You'll also need to install the Python client
for Bugsnag, with `pip install bugsnag`.
I removed the gunicorn requirement. At Runscope we need a custom version of
gunicorn, and the requirement isn't strictly necessary for third parties to
use this project. (They might want to host under a different WSGI server
anyway.)
Also updated the README to remove some Heroku references.
This endpoint conforms to RFC7233.
http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7233.html
It is functionally very similar to /stream-bytes, but it also
allows specifying a "Range" header, which allows the client
to ask for a specific portion of the resource.
I didn't add this functionality to /stream-bytes so as not
to break compatibility with any clients that expect range
requests to fail on that endpoint. Perhaps I'm just being
overly cautious.
that were broken by Markdown => reST conversion, by removing all double
backquotes. I don't think reST allows double backquote (code font)
nested inside a link.
Neil Mansilla