bucket_44/python-h11

   1 # Buildsheet autogenerated by ravenadm tool -- Do not edit.
   2
   3 NAMEBASE=               python-h11
   4 VERSION=                0.14.0
   5 KEYWORDS=               python
   6 VARIANTS=               v11 v12
   7 SDESC[v11]=             HTTP/1.1 implementation (3.11)
   8 SDESC[v12]=             HTTP/1.1 implementation (3.12)
   9 HOMEPAGE=               https://github.com/python-hyper/h11
  10 CONTACT=                Python_Automaton[python@ironwolf.systems]
  11
  12 DOWNLOAD_GROUPS=        main
  13 SITES[main]=            PYPIWHL/95/04/ff642e65ad6b90db43e668d70ffb6736436c7ce41fcc549f4e9472234127
  14 DISTFILE[1]=            h11-0.14.0-py3-none-any.whl:main
  15 DF_INDEX=               1
  16 SPKGS[v11]=             single
  17 SPKGS[v12]=             single
  18
  19 OPTIONS_AVAILABLE=      PY311 PY312
  20 OPTIONS_STANDARD=       none
  21 VOPTS[v11]=             PY311=ON PY312=OFF
  22 VOPTS[v12]=             PY311=OFF PY312=ON
  23
  24 DISTNAME=               h11-0.14.0.dist-info
  25
  26 GENERATED=              yes
  27
  28 [PY311].USES_ON=                        python:v11,wheel
  29
  30 [PY312].USES_ON=                        python:v12,wheel
  31
  32 [FILE:4042:descriptions/desc.single]
  33 h11
  34 ===
  35
  36    :alt: Automated test status
  37
  38    :alt: Test coverage
  39
  40    :alt: Documentation Status
  41
  42 This is a little HTTP/1.1 library written from scratch in Python,
  43 heavily inspired by `hyper-h2 <https://hyper-h2.readthedocs.io/>`_.
  44
  45 It's a "bring-your-own-I/O" library; h11 contains no IO code
  46 whatsoever. This means you can hook h11 up to your favorite network
  47 API, and that could be anything you want: synchronous, threaded,
  48 asynchronous, or your own implementation of [RFC 6214
  49 ] -- h11 won't judge you.
  50 (Compare this to the current state of the art, where every time a [new
  51 network API] comes along then someone
  52 gets to start over reimplementing the entire HTTP protocol from
  53 scratch.) Cory Benfield made an [excellent blog post describing the
  54 benefits of this approach
  55 ], or if you like video
  56 then here's his [PyCon 2016 talk on the same theme
  57 ].
  58
  59 This also means that h11 is not immediately useful out of the box:
  60 it's a toolkit for building programs that speak HTTP, not something
  61 that could directly replace requests or ``twisted.web`` or
  62 whatever. But h11 makes it much easier to implement something like
  63 requests or ``twisted.web``.
  64
  65 At a high level, working with h11 goes like this:
  66
  67 1) First, create an ``h11.Connection`` object to track the state of a
  68    single HTTP/1.1 connection.
  69
  70 2) When you read data off the network, pass it to
  71    ``conn.receive_data(...)``; you'll get back a list of objects
  72    representing high-level HTTP "events".
  73
  74 3) When you want to send a high-level HTTP event, create the
  75    corresponding "event" object and pass it to ``conn.send(...)``;
  76    this will give you back some bytes that you can then push out
  77    through the network.
  78
  79 For example, a client might instantiate and then send a
  80 ``h11.Request`` object, then zero or more ``h11.Data`` objects for the
  81 request body (e.g., if this is a POST), and then a
  82 ``h11.EndOfMessage`` to indicate the end of the message. Then the
  83 server would then send back a ``h11.Response``, some ``h11.Data``, and
  84 its own ``h11.EndOfMessage``. If either side violates the protocol,
  85 you'll get a ``h11.ProtocolError`` exception.
  86
  87 h11 is suitable for implementing both servers and clients, and has a
  88 pleasantly symmetric API: the events you send as a client are exactly
  89 the ones that you receive as a server and vice-versa.
  90
  91 [Here's an example of a tiny HTTP client
  92 ]
  93
  94 It also has [a fine manual].
  95
  96 FAQ
  97 ---
  98
  99 *Whyyyyy?*
 100
 101 I wanted to play with HTTP in [Curio
 102 ] and [Trio
 103 ], which at the time didn't have any
 104 HTTP libraries. So I thought, no big deal, Python has, like, a dozen
 105 different implementations of HTTP, surely I can find one that's
 106 reusable. I didn't find one, but I did find Cory's call-to-arms
 107 blog-post. So I figured, well, fine, if I have to implement HTTP from
 108 scratch, at least I can make sure no-one *else* has to ever again.
 109
 110 *Should I use it?*
 111
 112 Maybe. You should be aware that it's a very young project. But, it's
 113 feature complete and has an exhaustive test-suite and complete docs,
 114 so the next step is for people to try using it and see how it goes
 115 :-). If you do then please let us know -- if nothing else we'll want
 116 to talk to you before making any incompatible changes!
 117
 118 *What are the features/limitations?*
 119
 120 Roughly speaking, it's trying to be a robust, complete, and non-hacky
 121 implementation of the first "chapter" of the HTTP/1.1 spec: `RFC 7230:
 122 HTTP/1.1 Message Syntax and Routing
 123 <https://tools.ietf.org/html/rfc7230>`_. That is, it mostly focuses on
 124 implementing HTTP at the level of taking bytes on and off the wire,
 125 and the headers related to that, and tries to be anal about spec
 126 conformance. It doesn't know about higher-level concerns like URL
 127 routing, conditional GETs, cross-origin cookie policies, or content
 128 negotiation. But it does know how to take care of framing,
 129 cross-version differences in keep-alive handling, and the "obsolete
 130 line folding" rule, so you can focus your energies on the hard /
 131 interesting parts for your application, and it tries to support the
 132 full specification in the sense that any useful HTTP/1.1 conformant
 133
 134
 135 [FILE:106:distinfo]
 136 e3fe4ac4b851c468cc8363d500db52c2ead036020723024a109d37346efaa761        58259 h11-0.14.0-py3-none-any.whl
 137