%global _empty_manifest_terminate_build 0 Name: python-h11 Version: 0.14.0 Release: 1 Summary: A pure-Python, bring-your-own-I/O implementation of HTTP/1.1 License: MIT URL: https://github.com/python-hyper/h11 Source0: https://mirrors.nju.edu.cn/pypi/web/packages/f5/38/3af3d3633a34a3316095b39c8e8fb4853a28a536e55d347bd8d8e9a14b03/h11-0.14.0.tar.gz BuildArch: noarch Requires: python3-typing-extensions %description This is a little HTTP/1.1 library written from scratch in Python, heavily inspired by `hyper-h2 `_. It's a "bring-your-own-I/O" library; h11 contains no IO code whatsoever. This means you can hook h11 up to your favorite network API, and that could be anything you want: synchronous, threaded, asynchronous, or your own implementation of `RFC 6214 `_ -- h11 won't judge you. (Compare this to the current state of the art, where every time a `new network API `_ comes along then someone gets to start over reimplementing the entire HTTP protocol from scratch.) Cory Benfield made an `excellent blog post describing the benefits of this approach `_, or if you like video then here's his `PyCon 2016 talk on the same theme `_. This also means that h11 is not immediately useful out of the box: it's a toolkit for building programs that speak HTTP, not something that could directly replace ``requests`` or ``twisted.web`` or whatever. But h11 makes it much easier to implement something like ``requests`` or ``twisted.web``. At a high level, working with h11 goes like this: 1) First, create an ``h11.Connection`` object to track the state of a single HTTP/1.1 connection. 2) When you read data off the network, pass it to ``conn.receive_data(...)``; you'll get back a list of objects representing high-level HTTP "events". 3) When you want to send a high-level HTTP event, create the corresponding "event" object and pass it to ``conn.send(...)``; this will give you back some bytes that you can then push out through the network. For example, a client might instantiate and then send a ``h11.Request`` object, then zero or more ``h11.Data`` objects for the request body (e.g., if this is a POST), and then a ``h11.EndOfMessage`` to indicate the end of the message. Then the server would then send back a ``h11.Response``, some ``h11.Data``, and its own ``h11.EndOfMessage``. If either side violates the protocol, you'll get a ``h11.ProtocolError`` exception. h11 is suitable for implementing both servers and clients, and has a pleasantly symmetric API: the events you send as a client are exactly the ones that you receive as a server and vice-versa. `Here's an example of a tiny HTTP client `_ It also has `a fine manual `_. %package -n python3-h11 Summary: A pure-Python, bring-your-own-I/O implementation of HTTP/1.1 Provides: python-h11 BuildRequires: python3-devel BuildRequires: python3-setuptools BuildRequires: python3-pip %description -n python3-h11 This is a little HTTP/1.1 library written from scratch in Python, heavily inspired by `hyper-h2 `_. It's a "bring-your-own-I/O" library; h11 contains no IO code whatsoever. This means you can hook h11 up to your favorite network API, and that could be anything you want: synchronous, threaded, asynchronous, or your own implementation of `RFC 6214 `_ -- h11 won't judge you. (Compare this to the current state of the art, where every time a `new network API `_ comes along then someone gets to start over reimplementing the entire HTTP protocol from scratch.) Cory Benfield made an `excellent blog post describing the benefits of this approach `_, or if you like video then here's his `PyCon 2016 talk on the same theme `_. This also means that h11 is not immediately useful out of the box: it's a toolkit for building programs that speak HTTP, not something that could directly replace ``requests`` or ``twisted.web`` or whatever. But h11 makes it much easier to implement something like ``requests`` or ``twisted.web``. At a high level, working with h11 goes like this: 1) First, create an ``h11.Connection`` object to track the state of a single HTTP/1.1 connection. 2) When you read data off the network, pass it to ``conn.receive_data(...)``; you'll get back a list of objects representing high-level HTTP "events". 3) When you want to send a high-level HTTP event, create the corresponding "event" object and pass it to ``conn.send(...)``; this will give you back some bytes that you can then push out through the network. For example, a client might instantiate and then send a ``h11.Request`` object, then zero or more ``h11.Data`` objects for the request body (e.g., if this is a POST), and then a ``h11.EndOfMessage`` to indicate the end of the message. Then the server would then send back a ``h11.Response``, some ``h11.Data``, and its own ``h11.EndOfMessage``. If either side violates the protocol, you'll get a ``h11.ProtocolError`` exception. h11 is suitable for implementing both servers and clients, and has a pleasantly symmetric API: the events you send as a client are exactly the ones that you receive as a server and vice-versa. `Here's an example of a tiny HTTP client `_ It also has `a fine manual `_. %package help Summary: Development documents and examples for h11 Provides: python3-h11-doc %description help This is a little HTTP/1.1 library written from scratch in Python, heavily inspired by `hyper-h2 `_. It's a "bring-your-own-I/O" library; h11 contains no IO code whatsoever. This means you can hook h11 up to your favorite network API, and that could be anything you want: synchronous, threaded, asynchronous, or your own implementation of `RFC 6214 `_ -- h11 won't judge you. (Compare this to the current state of the art, where every time a `new network API `_ comes along then someone gets to start over reimplementing the entire HTTP protocol from scratch.) Cory Benfield made an `excellent blog post describing the benefits of this approach `_, or if you like video then here's his `PyCon 2016 talk on the same theme `_. This also means that h11 is not immediately useful out of the box: it's a toolkit for building programs that speak HTTP, not something that could directly replace ``requests`` or ``twisted.web`` or whatever. But h11 makes it much easier to implement something like ``requests`` or ``twisted.web``. At a high level, working with h11 goes like this: 1) First, create an ``h11.Connection`` object to track the state of a single HTTP/1.1 connection. 2) When you read data off the network, pass it to ``conn.receive_data(...)``; you'll get back a list of objects representing high-level HTTP "events". 3) When you want to send a high-level HTTP event, create the corresponding "event" object and pass it to ``conn.send(...)``; this will give you back some bytes that you can then push out through the network. For example, a client might instantiate and then send a ``h11.Request`` object, then zero or more ``h11.Data`` objects for the request body (e.g., if this is a POST), and then a ``h11.EndOfMessage`` to indicate the end of the message. Then the server would then send back a ``h11.Response``, some ``h11.Data``, and its own ``h11.EndOfMessage``. If either side violates the protocol, you'll get a ``h11.ProtocolError`` exception. h11 is suitable for implementing both servers and clients, and has a pleasantly symmetric API: the events you send as a client are exactly the ones that you receive as a server and vice-versa. `Here's an example of a tiny HTTP client `_ It also has `a fine manual `_. %prep %autosetup -n h11-0.14.0 %build %py3_build %install %py3_install install -d -m755 %{buildroot}/%{_pkgdocdir} if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi pushd %{buildroot} if [ -d usr/lib ]; then find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/lib64 ]; then find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/bin ]; then find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/sbin ]; then find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst fi touch doclist.lst if [ -d usr/share/man ]; then find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst fi popd mv %{buildroot}/filelist.lst . mv %{buildroot}/doclist.lst . %files -n python3-h11 -f filelist.lst %dir %{python3_sitelib}/* %files help -f doclist.lst %{_docdir}/* %changelog * Fri Apr 21 2023 Python_Bot - 0.14.0-1 - Package Spec generated