Can one http request have multiple responses? (Response codes out of range 1XX)
Is such functionality supported by clients/servers?
client ----request-----------> server
client <---response1 (402)---- server
client <---responsen2 (202)--- server
...
client <---responseN (200)---- server
No. In HTTP, one request gets one response. The client must send a second request to get a second response.
An HTTP request can have multiple "header responses", but the responses all have status codes in the 1xx range, such as 102 Processing. However, these responses are only headers, never bodies. Sending a response unsolicited is not allowed.
Related
Am a newbie to REST framework Http Status Codes.
Creating an API which accepts a request from the client and sends the response back with the information they need to include in the request.
Example:
If a client sends the invalid account number or account number with conflict.API will return a message that account number is invalid or some message describing the error in the request. I cant send it as 201 or 200 since it's not a success also it can't be a 400 (not bad data since it's a valid one)
What is the Status code I should use for this scenario?
The user sends a valid data even though due to some case user needs to acknowledge the request he sent. API will return a message with validation detail and he needs to send back the request with the validation message
In this case, I can send 200 or 201 for the second request with validation details.. What should I return for the first request?
If the request will never work as sent then 400 is the correct response. A 400 does not mean that an individual item in the request is invalid, it means the request as a whole is invalid. So if fields are missing then 400 is the correct response.
This is up to you what you will choose according to the condition but I am sharing list of Standard HTTP Status Code here so you can check the below link and choose Code according to the condition
https://github.com/prettymuchbryce/node-http-status
For your current scenario 400 will be a suitable :)
In my test case, I perform the http().receive() action for each expected request to the citrus http server.
Now I'd like to verify that there weren't any more requests after the expected ones. How do I accomplish that?
You can use the receiveTimeout() test action that expects that no messages are received on a given endpoint:
receiveTimeout(httpServer)
.timeout(5000);
This will make sure that no requests are received from 'httpServer' endpoint for 5000 ms. The action fails in case a message arrives at this endpoint in that time.
Suppose client call server using GET API, is it possible that server send a response but client misses that response??
If yes how to handle such situation, as I want to make sure that client receives the data. For now I am using second REST call by client as ack of first.
It is certainly possible. For example if you are using a site with a REST API and a request is just sent to the API and your internet connection dies when the answer is supposed to arrive, then it is quite possible that the server has received your request, successfully handled it, even sent the response, but your computer did not receive it. It could be an issue on a server responsible for transmitting the request as well. The solution to this kind of issue is to have a timeout and if a request timed out, then resend it until it is no longer timed out.
Is a client SOAP request simply the use of HTTP POST to send a correctly formatted HTTP header followed by the correctly formatted XML SOAP content to the web service server over a TCP/IP socket connection and then waiting for and parsing the response?
Is it this 'simple' or is there more going on behind the scenes?
I ask because of difficulty using gSOAP with C++ for multiple WSDL files and am considering writing a client from scratch.
SOAP can be used over any transport protocol like TCP, HTTP, SMTP etc with HTTP being the most popular.
SOAP over HTTP basically translates to a valid POST HTTP request with a SOAP envelope inside it, there where the form parameters would have been if we were to talk about a classic POST from the browser. The response body also contains a SOAP envelope, there where you would expect the HTML to be as response to the request from the browser.
You just have to use the proper content type for the SOAP version you are using (text/xml for SOAP 1.1 and application/soap+xml for SOAP 1.2) and maybe specify the SOAPAction header if needed (for SOAP 1.1), but that's about it as HTTP communication is concerned.
Then the receiver of the envelope (be it the server on a request or the client on a response) must make use of the SOAP message, but this has nothing to do with HTTP any more, HTTP just got the message there.
I'm trying to upload a file onto my personal server.
I've written a small php page that works flawlessy so far.
The little weird thing is the fact that I generate all the body of the HTTP message I'm going to send (let's say that amounts to ~4 mb) and then I send the request to my server.
The server, then, asks for an HTTP challenge and my delegate connection:didReceiveAuthenticationChallenge:challenge replies to the server with the proper credentials and the data.
But, what's happened? The data has been sent twice!
In fact I've noticed that when I added the progressbar.. the apps sends the data (4mb), the server asks for authentication, the apps re-sends the data with the authentication (another 4mb). So, at the end, I've sent 8mb. That's wrong.
I started googling and searching for a solution but I can't figure out how to fix this.
The case scenarios are two (my guess):
Share the realm for the whole session (a minimal HTTP request, then challenge, then data)
Use the synchronized way to perform an HTTP connection (things that I do not want to do since it seems an ugly way to handle this kind of stuff to me)
Thank you
You've run into a flaw into the http protocol: you have to send all the data before getting the response with the auth challenge (when you send a request with no credentials). You can try doing a small round trip as the first request in the same session (as you've mentioned), like a HEAD request, then future requests will share the same nonce.
Too late to answer the original requester, but in time if somebody else read this.
TL;DR: Section 8.2.3 of RFC 2616 describes the 100 Continue status which is all what you need (were needing) in such a situation.
Also have a look at sections 10.1.1 and 14.20.
The client sends a request with an "Expect: 100-continue" header, pausing the request before sending the body. The server uses the already received headers to make its decision whether this request may be accepted or not (if the entity –the body– to be received is not too large, if the user's credentials are correct...). If the request is acceptable for the server, it replies with a "100 Continue" status code, the client sends the body and the server replies with the final status code for that request. To the contrary, if the request is not acceptable, the server replies with a 4xx status code ("413 Request Entity Too Large" if the provided body size is... too large, or a "401 Unauthorized" + the WWW-Authenticate: header) and the client does not send the body. Being answered with a 401 status code and the corresponding WWW-Authenticate: information, the client can now perform the request again and provides its credentials.