In many places, read WS-Addressing is not built for HTTP? HTTP don't need asynchronous communication? What if A sends request to B and want B reply to C?
Like:
What is WS-Addressing good for? the reply said "But wait... HTTP connection? Why should I care about that? "
The "WS-Addressing for Developers" section of this introduction from oracle said "... WS-Addressing is not a revolution. Because an HTTP request and response occur synchronously over a single HTTP connection ..."
Related
For educational purposes I am trying to make a web api in c++. the web api needs to be able to listen for http requests(GET, POST etc.), when it receives a http request it needs to be able to send data back to the client. Because it is for educational purposes I would like to do it without unnecessary libraries. Now the first thing I need to do is make the api able to receive requests and respond on that, after some research on google I found out that winsock is probably the most basic way to setup sockets for windows but I could find very little on receiving http requests.
My question is: Is it possible with winsock to receive a http request from the browser, and send data back to the browser?.
My question is: Is it possible with winsock to receive a http request from the browser, and send data back to the browser?
Yes. ^^
It is, Because HTTP is a protocol that (usually) uses TCP as the underlying transportation protocol.
But trying to build a real HTTP layer on top of a simple win32 socket is a bit too much even for an experienced C++ developer.
Many un-experienced C++ developers would probably dismiss this task as a "well, you just need to read some data, parse the headers, assemble your own HTTP response and send it back".
but..
You will have to support
TLS, with all the nasty private keys/public keys implementation
Redirection
Chunked Transfer
G-Zip transfer
and the list goes on and on..
So practically speaking, if you just want to to accept a socket, read some data and send some basic HTTP response than yes. If you want a reliable, professional HTTP library - probably no.
You can check this page https://github.com/ReneNyffenegger/cpp-webserver to see simple winsock server implementation for HTTP. Web server implementation is not so difficult. Of course you should have time for it.
I have a tornado HTTP server.
How can I implement broad-cast message with the tornado server?
Is there any function for that or I just have to send normal HTTP message all clients looping.
I think if I send normal HTTP message, the server should wait for the response.
It seems not the concept of broad-cast.
Otherwise, I need another third-part option for broad-cast?
Please give me any suggestion to implement broad-cast message.
Short answer: you might be interested in WebSockets. Tornado seems to have support for this.
Longer answer: I assume you're referring to broadcast from the server to all the clients.
Unfortunately that's not doable conceptually in HTTP/1.1 because of the way it's thought out. The client asks something of the server, and the server responds, independently of all the others.
Furthermore, while there is no request going on between a client and a server, that relationship can be said to not exist at all. So if you were to broadcast, you'd be missing out on clients not currently communicating with the server.
Granted, things are not as simple. Many clients keep a long-lived TCP connection when talking to the server, and pipeline HTTP requests for it on that. Also, a single request is not atomic, and the response is sent in packets. People implemented server-push/long-polling before WebSockets or HTTP/2 with this approach, but there are better ways to go about this now.
There is no built-in idea of a broadcast message in Tornado. The websocket chat demo included with Tornado demonstrates how to loop over the list of clients sending a message to each:
def send_updates(cls, chat):
logging.info("sending message to %d waiters", len(cls.waiters))
for waiter in cls.waiters:
try:
waiter.write_message(chat)
except:
logging.error("Error sending message", exc_info=True)
See https://github.com/tornadoweb/tornado/blob/master/demos/websocket/chatdemo.py
I've been searching for a solution on StackOverFlow and couldn't seem to find an answer, I am using WinSock2 to log into a website and the server responds with "Connection: close" (Even if I send Connection: keep-alive) in the header. Any messages attempting to recv after returns 0. (0 = Graceful close)
Questions:
Is the connection suppose to drop after a POST request?
How do you send subsequent GET/POST requests after it has dropped?
So do you have to recycle the socket and re-establish everything again like my example below?
Example of list of events (that i'd imagine i'd need to do):
WSAStartup
Find Address
Create socket
Connect Socket with address
Send Post Request
---Connection Closes after Post---
Destroy Socket
Create socket
Connect Socket with address
Send Get Request with Authentication Cookie
This is what I picture the event chain would look like, but I am not 100% sure how browsers handle all this. But I learn from other users experience and input so if anyone knows exactly what happens let me know. Thank you for your time,
Is the connection suppose to drop after a POST request?
It can, yes. HTTP is a stateless protocol, there is no guarantee that the connection will stay alive after a response, even if a keep-alive is requested. Whether or not to close the connection after sending the response is up to the server to decide, if the client does not request the connection to be closed.
How do you send subsequent GET/POST requests after it has dropped?
You have no choice but to reconnect to the server, and everything that involves (TCP handshakes, SSL/TLS handshakes, etc) before you can send the new request.
If you:
send an HTTP 1.0 request that does not explicitly state Connection: keep-alive, or receive an HTTP 1.0 response that does not explicitly state Connection: keep-alive
send an HTTP 1.1 request that explicitly states Connection: close, or receive an HTTP 1.1 response that explicitly states Connection: close
Then you must close your end of the connection after reading the response.
Even if the response indicates a keep-alive is in effect, the connection could still timeout and be closed before you send your next request on the same connection.
So, any time you want to send a new request, if the connection has already been closed previously, or you get a connection error while sending the request, close the socket, reconnect, and resend the request.
So do you have to recycle the socket and re-establish everything again like my example below?
Potentially, yes.
I am not 100% sure how browsers handle all this.
Exactly as described above.
This is discussed further in RFC 2616 Section 8 "Connections".
We have a server process that replies to HTTP POST only.
The framework that I use, gsoap, provides an HTTP GET plugin.
I would like to ask what is the purpose of http GET in soap. What are the benefits?
Could you please share your experience, if any?
It represents different message exchange pattern. When you send POST you are issuing SOAP request and receiving SOAP response - that is called request-response message exchange pattern. When using GET you are calling "resource" by URI and including Accept HTTP header to request SOAP response - that is called response message exchange pattern.
These two patterns are used with HTTP binding defined in SOAP 1.2 (not every API supports this binding). Each message exchange pattern has its own purpose:
Response message exchange pattern is only for data retrieval. It should never change any data on the server.
Request/response message exchange pattern is for both retrieval and data modification on the server.
The benefit of HTTP GET can be anything related to differences between GET request and POST request. For example responses to HTTP GET requests can be cached on HTTP proxies.
I am just getting started with SOAP web services and stumbled across WS-Addressing.
I have read the Wikipedia page, but I'm having a hard time understanding just what the point of WS-Addressing is.
According to Wikipedia and various sources on the web, WS-Addressing allows to put "addressing information" or "routing information" into the header of a SOAP request.
Why is this useful? If I send a request via HTTP (or even via SMTP or UDP), then the address I send to is the address of the server which will process my request, and the server can simply reply by the same channel. So why is addressing/routing information needed?
I'd be particularly interested in some real-world (more or less) example where WS-Addressing is helpful.
I've found WS-Addressing particularly useful in situations where the SOAP response can't be served immediately. Either the resources to form the response are not available right away or the result itself takes a long time to be generated.
That can happen when your business process involves "a human touch" for example (processes like the ones WS-HumanTask is targeting). You can stick web services in front of your business, but sometimes business takes time. It might be a subscription that must be manually verified, something to be approved, whatever, but it takes days to do it. Are you going to keep the connection opened all that time? Are you going to do nothing else than wait for the response? No! That is inefficient.
What you need is a notification process. The client makes a requests but does not wait for the response. It instead instructs the server where to send the response by use of a "reply to" address. Once the response is available, the server connects to that address and sends the response.
And voila... asynchronous interactions between web services, decoupling the lifetime of the communication process from the lifetime of the HTTP connection. Very useful...
But wait... HTTP connection? Why should I care about that? What if I want the response sent back on another type of protocol? (which SOAP kindly provides as it is not tied to any protocol).
With normal request/response flow, the response comes on the same channel as the request 'cose it's a connection you know.... So for example you have a HTTP connection... that means HTTP in and HTTP out.
But with WS-Addressing you are not tied to that. You can demand the response on another type of channel. Request comes on HTTP for example, but you can instruct the server to send the response back over SMTP, for example.
In this way WS-Addressing defines standard ways
to route a message over multiple transports. As the wiki page is saying:
instead of relying on network-level transport to convey routing information,
a message utilizing WS-Addressing may contain its own dispatch metadata in a standardized SOAP header.
and as for your observation:
and the server can simply reply by the same channel
... what works for some, might not work for others, and for others we have WS-Addressing :D.