HTTP follows the request-response model, i.e. for every request from a client there will be a response from the server.
Does there exist any protocol that follows only request model (there will be only requests from client)?
I know SMTP. Can I consider SMTP as request only model because we are sending the mail but not receiving any response from server?
If there exists any other such protocol, please explain about it. I googled it but didn't find any answer related to my specific query.
Can I consider SMTP as request only model because we are sending the mail but not receiving any response from server?
No, because for every command the client sends to the SMTP server, the client gets a response. SMTP is a lot more chattier than HTTP. Just to send a single email, an SMTP server and a client communicate with each other at least 5 times.
This is how SMTP works:
Client: EHLO yourdomain.com
Server: 250 smtp.gmail.com
Client: MAIL FROM: you#yourdomain.com
Server: 250 Ok
Client: RCPT TO: someone#gmail.com
Server: 250 Ok
Client: DATA
Server: 354 Start mail input; end with <CRLF>.<CRLF>
Client: Hey how are you?
Client: .
Server: 250 Ok
Client: QUIT
Server: 221 smtp.gmail.com Closing connection. Goodbye!
As you can see, this is also a request-response protocol.
But the Wikipedia page that you linked says that SMTP is a one-way protocol, which is wrong.
Does there exist any protocol that follows only request model (there will be only requests from client)?
Most protocols are there for exchanging data, that is why they follow the request-response model. The client wants to see a page, so he requests it from the server and then the server sends the page in response. The data is being exchanged between the server and the client.
But if you want you can write a protocol which is one way only.
Related
if an HTTP client reaches a website through a proxy (not reverse proxy) server, what are the actual HTTP request and its parameters that are sent from this client host to the internet?
for example:
Proxy Server: www.proxy.com:80
Target website: www.website.com:8081
Does the HTTP client send the following Get request?
Get http://www.proxy.com:80
Host: www.proxy.com:80
OR
Get http://www.website.com:8081
Host: www.website.com:8081
if the first case is true, How can the proxy know what is the actual destination to forward this request?
otherwise, if the second is true, how can the request actually reach the proxy host machine?
When you want to issue a GET request to http://www.example.com:8081/index.html, the browser connects to www.example.com:8081 and sends the following request:
GET /index.html HTTP/1.1
Host: www.example.com:8081
Now when a proxy is configured, say www.proxy.com:80, the browser will connect to www.proxy.com:80 instead, and issue the following request:
GET http://www.example.com:8081/index.html HTTP/1.1
Host: www.example.com:8081
So when a proxy is configured, the HTTP client connects to the proxy instead of to the target server, and sends the request using the absolute URI.
The client doesn't have to change the HTTP request for it to be sent to a proxy. It has to change the TCP headers.
The screenshot below shows a HTTP request sent from my browser to a proxy, as you can see nothing in the HTTP request itself specifies the proxy.
How this works is the browser/client will issue a HTTP GET request, which will then be forwarded to the TCP/IP stack and wrapped in a TCP header. The TCP header is where the destination is specified (proxy or otherwise).
Http proxy server can read http headers.
Whenever we use http proxy the destination address in the tcp packet(originating from client) has destination address of proxy server..
When the proxy server receives the tcp packet it can read the http headers(which is present in tcp packet payload) the http headers contains the actual destination for the packet.. using this information the http proxy server can forward the packet to actual destination.
Source : https://www.ibm.com/support/knowledgecenter/SSBLQQ_9.1.0/com.ibm.rational.ritpp.install.doc/topics/c_ritpp_advanced_proxy.html
I'm building a HTTP client(for embedded devices) and I was wondering,
If I receive a HTTP 3xx response, and in the location header I get a hostname different from the one I had in the request. Should I disconnect the TCP connection and reconnect to the new host, or I just need to send a new request with a new host header and keep the old TCP connection alive.
Thank you
It doesn't make sense to reuse the original TCP connection if you're being redirected elsewhere. If my webserver only hosts example.com and I redirect you to elsewhere.net, my webserver will probably not respond to a request for elsewhere.net.
Worse, this also potentially sets you up for a great man-in-the-middle attack if my server redirects you to http://bank.com and you reuse the same TCP connection when sending a request to bank.com. My server can maliciously respond to requests with Host: bank.com, which isn't something you want to happen.
You can't assume the original connection can be reused unless the redirect is to the same same host with the same protocol.
Persistent HTTP connections are a little tricky with the number of client/server combinations. You can avoid the complexity by just wasting time closing and re-establishing each connection:
If you're implementing a HTTP/1.0 client, Connection: keep-alive isn't something you have to implement. Compliant servers should just close the connection after every request if you don't negotiate that you support persistent connections.
If you're implementing a HTTP/1.1 client and don't want to persist the connection, just send Connection: close with your request and a HTTP/1.1 server should close the connection.
We are trying to make a secure communication between our embedded system and web server.Firstly we implement HTTP connection to in our microcontroller. I am just connecting to 80 port of my web server and send simple GET request to this port as example below :
GET /foo.php?msg=test HTTP/1.1
HOST: foo.com
My questions is,How we will turn this to HTTPS ? Which port i should connect ?
Will be any difference on structure of GET request above ? Will i have to do some encryption manually or connect to "https" link instead "http" is enuogh for secure communication.
Thanks for any information
The only difference between a HTTP request and a HTTPS request is that the first is send over a plain TCP connection while the other is send over a TLS connection, i.e.:
with HTTP you establish a TCP connection and send the request over this connection
with HTTPS you establish a TCP connection, upgrade this connection to TLS (including proper certificate validation etc!) and then send the same request as you did with HTTP over this connection.
Apart from that I recommend to either use an established library for HTTP or carefully read the standard. Although HTTP looks simply it is actually not and there are many questions here where users try to do a simply HTTP request and trip over behavior they did not expect.
For example in your case the server might send the response with chunked encoding, with content-length or simply end it with connection close. And it might wait for further requests on the same connection since HTTP/1.1 implicitly enables HTTP keep-alive. Does your code really account for all these cases?
I have two questions on HTTP Connection close:
If a client sends a HTTP request with Connection: close to HTTP Server, Is it the HTTP Server or client responsibility to send TCP FIN after response is received by client?
If a client sends a bad formatted HTTP request, and server sends a 400 BAD REQUEST, is it best practice to close the connection by server (even though the HTTP request has connection: keep-alive) or is it good practice to keep the connection still active?
Thanks in advance for answering my queries?
When the server receives a 400 Bad Request, it is going to send the response with the keep-alive header because if the client feels like sending another request, then they can use a pre-existing connection (this connection is shut down within a certain amount of time, it has an expiration date). The Keep-Alive Header is more about not saturating the network with TCP connection demands. You basically say "I am going to talk to you, for 2 minutes, whatever you send me, I'll answer you though this connection"
The server is only an object that receives commands from an user. You ask him, he does or not. The TCP FIN is something you send to the server to shut down the connection, but you choose when you don't want to communicate with him anymore. The client transmits the first FIN, and receives an ACK to ensure that the server got it. Then the server launches its own FIN, and waits for the ACK. If everything is okay, you and your server are no longer friends.
We have 120+ clients using PJSIP calling into the same conference room in a Freeswitch server via a cellular network. Freeswitch accepts the first INVITE of a client then sends auth challenge back. Since the second INVITE packet size is > 1300 PJSIP sends the second INVITE with the proxy auth in TCP. For 60%+ of the calls the Freeswitch server is closing the TCP connection. A dump of wireshark trace would look like:
From client: INVITE
From server: 100 trying
From server: 407 proxy auth required
From client: ACK PJSIP acks the first INVITE on UDP
From client: SYN
From FS: SYN,ACK
From client: ACK
From FS: FIN,ACK
From client: ACK
From client: [TCP segment of a reassembled PDU]
From client: INVITE - with the proxy auth
From FS: RST,ACK
From FS: RST
Call fails - Freeswitch does not receive the second invite because the connection is closed. Cannot figure out why the server is closing the connection. It almost looks random.
When the calls start coming in some clients make it some don't. It's not just the first 50 or so. During the call the server cpu goes to about 60%. The call can last around 4 minutes.
The Freeswitch logs do not show TCP failure.
I have set the following:
In \FreeSwitch\conf\sip_profiles\internal.xml
<param name="debug" value="9"/>
<param name="sip-trace" value="on/>
In \FreeSwitch\conf\autoload_configs\sofia.conf.xml
<param name="log-level" value="9"/>
<param name="tracelevel" value="DEBUG"/>
About 50 of 120 clients make the call. The client will periodically keep trying to join the call if it fails until some specified end of call timer is reached.
The Server is a Windows Server 2008 R2 Standard 64-bit 8Gb 2 2.6Ghz procs
Any help in how to continue troubleshooting this problem would be greatly appreciated.
Lou
Lou, I think this question belongs to serverfault.com, not stackoverflow.
I'd suggest you to try to connect to the FreeSWITCH server with a different SIP client, like Zoiper, and test how it works in TCP-only mode.