I would like to use python-requests in my server to send PUSH notification to Apple push server, my questions:
Does python-requests support asynchronous calls ?
Does python-request support HTTP2 ?
Thanks
As recommended by #qris in this comment, you should consider using HTTPX (https://github.com/encode/httpx/) .
It's in beta, but a 1.0 release is planned.
It supports both async as well as HTTP/2 and provides a requests-compatible API.
It doesn't support HTTP/2 now (Release v2.18.1).
As in the doc (http://docs.python-requests.org/en/master/):
Requests allows you to send organic, grass-fed HTTP/1.1 requests, without the need for manual labor.
But you can try Hyper if you need to send HTTP/2 requests:
https://hyper.readthedocs.io/en/latest/.
hyper supports Python 3.4 and Python 2.7.9, and can speak HTTP/2 and HTTP/1.1.
Related
Since HTTP/2.0 leverages request multiplexing, I've been wondering whether using HTTP/2.0 over HTTP/1.1 for HLS streaming.
My current HLS stream seems to be using HTTP/1.1, at least, that's what I gathered when I inspected my Native HLS Playback Chrome extension in the network tab, with all the Media Playlists and TS chunks being transfered over HTTP/1.1.
At this point, I've found no information on HLS over HTTP/2.0, but some info on MPEG-DASH over HTTP/2.0, so I'm wondering whether HLS over HTTP/2.0 is even possible. If it is, will I get lower latency between server and client devices?
Related question: does Exoplayer support HLS over HTTP/2.0?
Yes, it is possible, no it won’t reduce latency.
Apple released recently its spec for low latency. It includes HTTP/2 push support for very low latency.
See their specification here
It'll probably deliver your video data as fast as other real-time protocol into safari and iOS. :)
HLS and Dash are protocols on top of HTTP, and are e.g. defined in terms of HTTP GET requests. They will work on HTTP/1.1 as well as HTTP/2. The only question is whether the client supports HTTP/2, and whether the server which is serving the stream supports HTTP/2. Those questions would need to be asked for each application individually.
My estimate is that HTTP/2 support wouldn't yield too much advantage for those use-cases. HTTP/2 is best at multiplexing lots of small requests over a single TCP connection, and avoiding the overhead of creating new connections. With video streaming, there are not that many concurrent small requests - instead the client fetches larger chunks piece by piece. This should work pretty fine on top of HTTP/1.1 connections with keep-alive (which also doesn't require a new connection per request - it just doesn't support parallel requests).
HTTP/1.1 might be even more efficient than HTTP/2 for this special use-case, since there is not the overhead of another flow-control mechanism on top of TCP.
What does operations are done with gRPC, over HTTP/2 means. I am interested in knowing how does gRPC and HTTP/2 play along.
gRPC is a protocol that uses HTTP/2. The messages you send are encoded as gRPC frames (5 byte header) and packaged into HTTP/2 DATA frames. The HTTP/2 HEADERS frames are used to propagate headers and trailers at the beginning and end of the call.
It would be possible to use gRPC over other protocols, though this is less common as of this writing. For example:
gRPC can be used In Process, meaning there is no wire encoding. You still get to use the same gRPC API and Stubs though. This is commonly used for testing
QUIC: This is a UDP based protocol that is an alternative to HTTP/2, but which has HTTP semantics. This is used on Android Java when using the AndroidChannelBuilder.
HTTP/1.1: This is used for gRPC Web. Some minor modifications are needed to the gRPC protocol, but it can work from regular web browsers which currently don't support certain parts of HTTP/2.
Does Paw.app support sending HTTP requests to UNIX sockets similar to curl --unix-socket=/tmp/my.sock?
Thanks!
--
-a
No, unfortunately, this isn't supported by Paw. Maybe later :) It should be doable as we have our own HTTP library. The limitations of OS X sandboxing may limit this, but we can find workarounds…
Why http based on request/response? Why server can't push data with http to client directly and must has to be response of client request? In start of connection I know that client has to send request but why after that client must continue request/response/req/resp. long polling, comet, Bosh and other server pushing method also based on req/resp method and not solve the question.
All your problems ok! RFC 6455 defines the WebSocket protocol. HTTP 1.1 supports bi-directional TCP-like sockets that do not require you follow the request/reply pattern. The original spec had only UTF-8 character coding support, but now with modern browsers, binary data can be sent down the wire as well. Working with WebSockets presents a new manner of framing a web application but it's growing browser support makes it a viable option for modern websites.
Node.js is the easiest way to get into using WebSocket's with the Socket.IO library. Do check it out.
I'm looking for standards that are behind realtime web applications.
I know about W3C Websockets API and IETF Websockets protocol, Bayeux protocol and Server-Sent Events standards.
Are there any other standards for techniques like long-polling, callback-polling, Iframe streaming, htmlfile streaming, XHR streaming, multipart streaming, Direct Socket?
Long polling doesn't have a dedicated standard. It is effectively an implementation technique layered on top of existing standards like HTTP and XMLHttpRequest (which is standardized as W3C working drafts). The Wikipedia page is a pretty good reference.
XMPP standardizes a technique called BOSH which is also implemented as long-lived HTTP.
multipart/x-mixed-replace was implemented by Netscape but not IE, and is not a standard. The Push technology Wikipedia page is a good reference.
Hope these help.
If anyone is interested in a Java implementation I just wrote a sample app and a blog post about it. It uses Java, Maven, Comet, Bayeux, Spring.
http://jaye.felipera.cloudbees.net/
http://geeks.aretotally.in/thinking-in-reverse-not-taking-orders-from-yo
I have found an interesting answer on quora (http://www.quora.com/What-are-the-standards-behind-realtime-web) :
The following protocols are core to the Realtime Web:
HTTP protocol in general makes so much possible WebSockets protocol
PubSubHubbub protocol
Webhooks eXtensible Messaging and Presence Protocol (XMPP) & BOSH
(http://xmpp.org/extensions/xep-0...)
Activity Streams (as pointed
out by Chris Saad)
http-live-streaming / HTTP Long-Polling