Mercurial > repos > rliterman > csp2

comparison CSP2/CSP2_env/env-d9b9114564458d9d-741b3de822f2aaca6c6caa4325c4afce/lib/python3.8/site-packages/h11-0.14.0.dist-info/METADATA @ 68:5028fdace37b

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
planemo upload commit 2e9511a184a1ca667c7be0c6321a36dc4e3d116d
author jpayne
date Tue, 18 Mar 2025 16:23:26 -0400
parents
children
comparison
equal deleted inserted replaced
67:0e9998148a16 68:5028fdace37b
1 Metadata-Version: 2.1
2 Name: h11
3 Version: 0.14.0
4 Summary: A pure-Python, bring-your-own-I/O implementation of HTTP/1.1
5 Home-page: https://github.com/python-hyper/h11
6 Author: Nathaniel J. Smith
7 Author-email: njs@pobox.com
8 License: MIT
9 Classifier: Development Status :: 3 - Alpha
10 Classifier: Intended Audience :: Developers
11 Classifier: License :: OSI Approved :: MIT License
12 Classifier: Programming Language :: Python :: Implementation :: CPython
13 Classifier: Programming Language :: Python :: Implementation :: PyPy
14 Classifier: Programming Language :: Python :: 3
15 Classifier: Programming Language :: Python :: 3 :: Only
16 Classifier: Programming Language :: Python :: 3.7
17 Classifier: Programming Language :: Python :: 3.8
18 Classifier: Programming Language :: Python :: 3.9
19 Classifier: Programming Language :: Python :: 3.10
20 Classifier: Topic :: Internet :: WWW/HTTP
21 Classifier: Topic :: System :: Networking
22 Requires-Python: >=3.7
23 License-File: LICENSE.txt
24 Requires-Dist: typing-extensions ; python_version < "3.8"
25
26 h11
27 ===
28
29 .. image:: https://travis-ci.org/python-hyper/h11.svg?branch=master
30 :target: https://travis-ci.org/python-hyper/h11
31 :alt: Automated test status
32
33 .. image:: https://codecov.io/gh/python-hyper/h11/branch/master/graph/badge.svg
34 :target: https://codecov.io/gh/python-hyper/h11
35 :alt: Test coverage
36
37 .. image:: https://readthedocs.org/projects/h11/badge/?version=latest
38 :target: http://h11.readthedocs.io/en/latest/?badge=latest
39 :alt: Documentation Status
40
41 This is a little HTTP/1.1 library written from scratch in Python,
42 heavily inspired by `hyper-h2 <https://hyper-h2.readthedocs.io/>`_.
43
44 It's a "bring-your-own-I/O" library; h11 contains no IO code
45 whatsoever. This means you can hook h11 up to your favorite network
46 API, and that could be anything you want: synchronous, threaded,
47 asynchronous, or your own implementation of `RFC 6214
48 <https://tools.ietf.org/html/rfc6214>`_ -- h11 won't judge you.
49 (Compare this to the current state of the art, where every time a `new
50 network API <https://trio.readthedocs.io/>`_ comes along then someone
51 gets to start over reimplementing the entire HTTP protocol from
52 scratch.) Cory Benfield made an `excellent blog post describing the
53 benefits of this approach
54 <https://lukasa.co.uk/2015/10/The_New_Hyper/>`_, or if you like video
55 then here's his `PyCon 2016 talk on the same theme
56 <https://www.youtube.com/watch?v=7cC3_jGwl_U>`_.
57
58 This also means that h11 is not immediately useful out of the box:
59 it's a toolkit for building programs that speak HTTP, not something
60 that could directly replace ``requests`` or ``twisted.web`` or
61 whatever. But h11 makes it much easier to implement something like
62 ``requests`` or ``twisted.web``.
63
64 At a high level, working with h11 goes like this:
65
66 1) First, create an ``h11.Connection`` object to track the state of a
67 single HTTP/1.1 connection.
68
69 2) When you read data off the network, pass it to
70 ``conn.receive_data(...)``; you'll get back a list of objects
71 representing high-level HTTP "events".
72
73 3) When you want to send a high-level HTTP event, create the
74 corresponding "event" object and pass it to ``conn.send(...)``;
75 this will give you back some bytes that you can then push out
76 through the network.
77
78 For example, a client might instantiate and then send a
79 ``h11.Request`` object, then zero or more ``h11.Data`` objects for the
80 request body (e.g., if this is a POST), and then a
81 ``h11.EndOfMessage`` to indicate the end of the message. Then the
82 server would then send back a ``h11.Response``, some ``h11.Data``, and
83 its own ``h11.EndOfMessage``. If either side violates the protocol,
84 you'll get a ``h11.ProtocolError`` exception.
85
86 h11 is suitable for implementing both servers and clients, and has a
87 pleasantly symmetric API: the events you send as a client are exactly
88 the ones that you receive as a server and vice-versa.
89
90 `Here's an example of a tiny HTTP client
91 <https://github.com/python-hyper/h11/blob/master/examples/basic-client.py>`_
92
93 It also has `a fine manual <https://h11.readthedocs.io/>`_.
94
95 FAQ
96 ---
97
98 *Whyyyyy?*
99
100 I wanted to play with HTTP in `Curio
101 <https://curio.readthedocs.io/en/latest/tutorial.html>`__ and `Trio
102 <https://trio.readthedocs.io>`__, which at the time didn't have any
103 HTTP libraries. So I thought, no big deal, Python has, like, a dozen
104 different implementations of HTTP, surely I can find one that's
105 reusable. I didn't find one, but I did find Cory's call-to-arms
106 blog-post. So I figured, well, fine, if I have to implement HTTP from
107 scratch, at least I can make sure no-one *else* has to ever again.
108
109 *Should I use it?*
110
111 Maybe. You should be aware that it's a very young project. But, it's
112 feature complete and has an exhaustive test-suite and complete docs,
113 so the next step is for people to try using it and see how it goes
114 :-). If you do then please let us know -- if nothing else we'll want
115 to talk to you before making any incompatible changes!
116
117 *What are the features/limitations?*
118
119 Roughly speaking, it's trying to be a robust, complete, and non-hacky
120 implementation of the first "chapter" of the HTTP/1.1 spec: `RFC 7230:
121 HTTP/1.1 Message Syntax and Routing
122 <https://tools.ietf.org/html/rfc7230>`_. That is, it mostly focuses on
123 implementing HTTP at the level of taking bytes on and off the wire,
124 and the headers related to that, and tries to be anal about spec
125 conformance. It doesn't know about higher-level concerns like URL
126 routing, conditional GETs, cross-origin cookie policies, or content
127 negotiation. But it does know how to take care of framing,
128 cross-version differences in keep-alive handling, and the "obsolete
129 line folding" rule, so you can focus your energies on the hard /
130 interesting parts for your application, and it tries to support the
131 full specification in the sense that any useful HTTP/1.1 conformant
132 application should be able to use h11.
133
134 It's pure Python, and has no dependencies outside of the standard
135 library.
136
137 It has a test suite with 100.0% coverage for both statements and
138 branches.
139
140 Currently it supports Python 3 (testing on 3.7-3.10) and PyPy 3.
141 The last Python 2-compatible version was h11 0.11.x.
142 (Originally it had a Cython wrapper for `http-parser
143 <https://github.com/nodejs/http-parser>`_ and a beautiful nested state
144 machine implemented with ``yield from`` to postprocess the output. But
145 I had to take these out -- the new *parser* needs fewer lines-of-code
146 than the old *parser wrapper*, is written in pure Python, uses no
147 exotic language syntax, and has more features. It's sad, really; that
148 old state machine was really slick. I just need a few sentences here
149 to mourn that.)
150
151 I don't know how fast it is. I haven't benchmarked or profiled it yet,
152 so it's probably got a few pointless hot spots, and I've been trying
153 to err on the side of simplicity and robustness instead of
154 micro-optimization. But at the architectural level I tried hard to
155 avoid fundamentally bad decisions, e.g., I believe that all the
156 parsing algorithms remain linear-time even in the face of pathological
157 input like slowloris, and there are no byte-by-byte loops. (I also
158 believe that it maintains bounded memory usage in the face of
159 arbitrary/pathological input.)
160
161 The whole library is ~800 lines-of-code. You can read and understand
162 the whole thing in less than an hour. Most of the energy invested in
163 this so far has been spent on trying to keep things simple by
164 minimizing special-cases and ad hoc state manipulation; even though it
165 is now quite small and simple, I'm still annoyed that I haven't
166 figured out how to make it even smaller and simpler. (Unfortunately,
167 HTTP does not lend itself to simplicity.)
168
169 The API is ~feature complete and I don't expect the general outlines
170 to change much, but you can't judge an API's ergonomics until you
171 actually document and use it, so I'd expect some changes in the
172 details.
173
174 *How do I try it?*
175
176 .. code-block:: sh
177
178 $ pip install h11
179 $ git clone git@github.com:python-hyper/h11
180 $ cd h11/examples
181 $ python basic-client.py
182
183 and go from there.
184
185 *License?*
186
187 MIT
188
189 *Code of conduct?*
190
191 Contributors are requested to follow our `code of conduct
192 <https://github.com/python-hyper/h11/blob/master/CODE_OF_CONDUCT.md>`_ in
193 all project spaces.