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.
Related
I will be happy to get advice from more experienced developers about adding Web Sockets into my HTTP-based project.
That’s the thing. I have developed the REST API based service. Everything works well enough, but… In some special cases my server needs a long time to serve client requests. It may be from 1 minute to several hours (and even days)! I implement some not-so-good algorithm to address this issue:
Client sends HTTP request
Server replies about registering request
Client starts sending HTTP requests to get necessary data (if response does not have needed information the client sends another request and so on)
That is all in a nutshell.
And it seems to be a bad scenario and I am trying to integrate web sockets for adding duplex-channels in this architecture. I hope that my API will be able to send info about updated data as soon as possible without the necessity of many requests from the client.
But I am a bit confused in choosing one of two ways to use web socket (WS).
Variant A.
The server only tells the client via WS that data is ready. And the client gets data by standard request-response HTTP method from REST API.
Variant B.
The server sends all data to the client via WS without HTTP at all.
What variant is more suitable? Or maybe some other variants?
I do not want to remove HTTP at all. I just try to implement WS for a particular kind of end-points.
Variant A would be more suitable and easy to implement. You can send message to the client after the data is ready, and he can then send request for the data. It will be like a simple chat websocket, and will serve your purpose.
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.
I want to connect from webserver via dedicated proxy to the intranet. I am not sure if it matters I want to send and receive XML. It would be great if I could use HTTP.
I know of one open port 78xx which I successfully used with a TCP socket as described in this excellent tutorial
Is it possible? Or does the answer depend on the actual proxy configuration - if it scans for the protocol, and dislikes it it's gonna be blocked!?
And what library would you recommend? I just found pion - Can i link it statically? It's almost not possible to install sth on the web server for me.
EDIT My question is probably two-fold:
First, I have to add, there is an existing communication client+server, but the server is a mixup of the concrete socket and networking implementation and the API to the database, consisting of about 10 commands I find hard to extend. So I ask for a generic lib so I can rewrite that API from scratch.
Second, I need session handling, the webapplication passes the user login data to that client and there is a session-id returned which is used for all further communication - until it expires. That was the reason I asked for HTTP, but meanwhile i realized http itself is stateless.
The answer is.... in progress.- I need to practice more with c++ tcp libs etc.
My post was unfortunately hard too understand, Had some confusion about that all.
I want to upload files from a client location to a server. At present, I have a client-server socket program by which I could send/receive files across, but I would like to improvise it.
My idea would be to transfer the file using HTTP PUT/POST from client (most of the coding on client side) to the server. Since I have no idea about HTTP programming, so I need some guidance on how to achieve that. I want to use C++ with BSD sockets in doing that, and no other libraries. My aim is to send the server a form, like as given below with a HTTP POST/PUT request, and get the file "main.cpp" uploaded to the server.
PUT http://localhost/ HTTP/1.0
Host: localhost
Content-type: form-data
Content-length: 90
FileUpload: /Users/SG/files/main.cpp
I was able to write a dummy program that does some PUT from a client, and the web server running Apache returns a HTTP 200. What I am failing to understand currently would be the following two things, which I guess are somewhat connected:
How one could specify a file to be uploaded from the client in the form above?
If I understand correctly, the file would be read at client site and then the file content would be sent to the server, where a server side script would read the bytes from client and create a copy of the file at the server. Is it correct?
Any help is appreciated.
Thanks,
Sayan
As stated it's not possible. C++ alone has no sockets API. (Edit: with the addition of a BSD sockets API, it's now possible).
Your implementation might provide an OS-specific sockets API, in which case your question boils down to, "how do I write an HTTP client?". To which the answer is (a) don't, or (b) read the HTTP specification very carefully and do as it tells you. The basic steps are:
(Possibly) parse a URL and use gethostbyname to get an IP address.
Open a TCP socket, using connect.
Write the request (you already have an idea what that looks like) using send.
Read the response using read.
Close the connection.
The difficult part is parsing the response robustly, because there are a lot of features to worry about. If your client is tied to a particular server, then its responses will be quite predictable, and you can ignore quite a lot of the HTTP spec (at least until you change the configuration of the server, update its software, etc).
If you're ready to give up before you finish, there are perfectly good HTTP libraries available, such as libcURL.
I want to use C++ for doing this,
without the help of any libraries or
system() calls.
Socket programming always requires system calls. C++ is an extremely general language. The ISO language definition does not specify anything about sockets or network programming, so in order to do this you need to rely on another system-specific library/standard, such as the BSD socket API on UNIX/Linux. Usually, in C++ you would use a higher-level third-party library that wraps these lower level system calls, such as Boost.ASIO. However, even that takes a bit of learning, to say nothing of correctly implementing the HTTP standard itself on top of your sockets.
I was able to attain what I wanted. My http post request string looks like below:
"POST %s HTTP/1.0\r\n"
"Host: %s\r\n"
"Content-type: multipart/form-data\r\n"
"Content-length: %d\r\n\r\n"
"Content-Disposition: %s; filename: %s\n"
I am sending the above string from a cpp program in client to the server, running Apache, which handles the data through a cgi script, also written in cpp. The data is placed with the Content Disposition attribute. Can anybody please point it out to me as to how would I transform the above to a HTTP PUT?
I am trying to send a SOAP request over HTTP for a web service through the following channels:
Telnet (HP-UX)
C client that opens a socket, writes XML and reads reasponse(HP-UX)
Perl client that does the same thing as the C client above(HP-UX)
Through SOAP UI application (http://www.soapui.org/)(Windows Machine)
While SOAP UI gets a response in about 100ms seconds or so; the rest of the channels get the same response but very slow.
I am wondering what might be the problem. If anybody has any idea about this please let me know.
Possibly the connection stays open per default for subsequent requests (not uncommon for webservers which expect you to request all kinds of javascript files, images, css files directly afterwards). You might want to try to send the Connection: close header.
Check the protocol , may be you are using HTTP1.0 not HTTP1.1