I already know the difference between POST and GET, but does the HTTP response changes when I make a request like:
GET / HTTP/1.1
Host: www.engadget.com
or
POST / HTTP/1.1
Host: www.engadget.com
I'm doing a basic web server (Can't use php or any server-side language) for an assignment so I need to know if the response changes or is basically the same.
It's up to the recipient of the request (server) to send back a response. The client can pass preferences to influence the response in the header (content type etc), but ultimately the response is determined by the server.
Related
I'm trying to send AT commands to my ESP32* module and am not getting any response back.
I need to perform a POST request that contains the username and password and other requests later on. I am not structuring these correctly and there is not a lot of good documentation for this.
NOTE: because I cannot share my complete url due to privacy I will use something with the same length ********connected.com:443
Send login information to ********connected.com/login (POST) body{"email":"myemail.ca", "password":"xxxxx"}
once I get the token I will make other requests.
get information regarding user profile ********connected.com/getRoutine ( GET) query param username="bob"
I really want to understand how these requests are structured so if someone can explain it to me elegantly that would be great!
Here is what I have tried..
AT
OK
AT+CIPSTART="TCP","********connected.com",443
CONNECT
OK
AT+CIPSEND=48
> "GET ********connected.com:443/getUsersOnline"
OK
>
Recv 48 bytes
SEND OK
CLOSED
REQUESTED POST REQUEST I HAVE USED
AT+CIPSEND=177 “POST \r Host: ********connected.com\r\n Accept: application/json\r\n Content-Length: 224r\n Content-Type: application/jsonr\n { "email":"myemail.com", "password":"myPassword" } “
There are actually several parts of your system that might be the cause of the malfunctioning:
The AT commands sent (it is not clear how you check for server responses. Responses could proviede clues about what's wrong)
The server side app seems to be a custom implementation that might have bugs as well
The POST request might be malformed
Let's focus on the last one.
POST are described in RFC 7231, and though it is an obscure description without examples, it makes one thing clear: there's not actually a well defined standard... because it is strictly application dependant!
I also quote the relevant part of this brilliant answer to an old SO question:
When receiving a POST request, you should always expect a "payload", or, in HTTP terms: a message body. The message body in itself is pretty useless, as there is no standard.
For this reason, all we can do is to build a POST request as accurate as possible and then to debug the system as a whole thing making sure that the request matches what expected by the server side application.
In order to do this, let's check another external link I found: POST request examples. We found this request:
POST /test HTTP/1.1
Host: foo.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
field1=value1&field2=value2
Now let's compare this example to your request:
POST
Host: ********connected.com
Accept: application/json
Content-Length: 224
Content-Type: application/jsonr
{ "email":"myemail.com", "password":"myPassword" }
You are saying to the server that you want to pass a resource to an unspecified application (no path), and that this resource is 224 bytes long (wrong! Message body is shorter).
For these reasons, at least these things can be improved:
POST /path/invic18app.php HTTP/1.1 //The path to the application and HTTP version are missing
Content-Length: 48 //This must be the length of the message body, without the header. I also would write it as the last option, just before message body
Write TWO empty lines before message body, otherwise the server will interpret it as further (wrong) options
I hope this helps you, even if it is a tentative answer (I cannot try this request myself). But, again, you definitely need to sniff packets a TCP levels, in order to avoid debugging the server if you are not sure that data is actually received! If you cannot install Wireshark, also tcpdump will be ok.
The code snippets generated from postman don't include whether it is HTTP or HTTPS
GET/apis/123?api-version=2017-03-01 HTTP/1.1
Host: contoso.anc.net
Content-Type: application/json
If-Match: *
Authorization: Bearer token
Cache-Control: no-cache
Postman-Token: fe465591-15b3-cbf0-9d9b-f2ed76efcb2c
The endpoint contoso.anc.net only responds to https endpoint and one of our customers had to figure out the hard way.
Is this missing information in the snippet or the service side should automatically bump to HTTPS when it gets a request over HTTP? Can somebody point to the spec?
Edit
This relates to the Generate Code Snippets that can be created within Postman using the code button.
The HTTP option:
By using console.log(pm.request) in the Tests tab you are able to see the request details in the Postman Console. This shows the Protocol as well as the other request data.
If the API is not telling you what protocol to use when making requests (In the documentation) or not giving the user any feedback within the response, that seems to me like a different problem your customer is facing.
I've been trying to thoroughly understand the HTTP POST request / response process and although there are a lot of resources on google, none plainly give me the answer I'm after.
Example scenario:
I have a search form, I enter some query and make the request. I then get redirected to the search result page.
Could someone explain this process; in particular, I'm most interested in the redirection.
This is what I think is going on:
POST request containing query
|
v
Server receives request.
|
V
Server sends back response containing the page that the client should subsequently request.
|
V
Client receives response and requests page indicated in the response.
|
V
Server receives request and sends back requested page.
|
V
Client renders page.
That's exactly what happens. See Post/Redirect/Get on Wikipedia for an explanation of this pattern.
The client performs the POST request:
Client -> Server: POST / HTTP/1.1 (+payload)
Server -> Client: HTTP/1.1 302 See other (+location header +payload)
Now the client sees the 302 and performs an additional request to the resource identified by the location header:
Client -> Server: GET $location HTTP/1.1
Server -> Client: HTTP/1.1 200 OK (+payload)
You can use Fiddler or Charles for inspecting HTTP traffic.
An HTTP POST request with content type "application/x-www-form-urlencoded" has parameters encoded in the body in the form of key=value pairs, concatenated with the & delimiter. Example from http://www.opencalais.com/HTTPexamples:
POST /enlighten/rest HTTP/1.1
Host: api.opencalais.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
licenseID=string&content=string¶msXML=string
I take it when a user fills out an ordinary POST form on a web page, the browser is not bound to any particular order of the key=value pairs when submitting the request.
However, does the HTTP protocol say anything about this order as the request is passed on by intermediate servers? Do any servers such as Apache, nginx, IIS rearrange the parameters? If such a POST request is sent to a server can one expect that the back-end server code (say PHP, Perl, Java) has access to the identical HTTP request body as sent?
Browsers are supposed to send application/x-www-form-urlencoded data in tree order. The spec doesn't make this very clear, but you can tease it out if you look carefully. See x-www-form-urlencoded-encoding-algorithm and Constructing the form data set. The decoding section also calls the output a "sorted list of name-value pairs".
So yes, a well-behaved proxy should preserve the order of form entries.
The HTTP OPTIONS method is supposedly used to determine what other methods the server supports on a given resource. Given that, I have two questions:
What does this response look like? I have seen examples with CSV lists in Public, Allow, and even Access-Control-Allow-Methods headers. Are they all needed? What's the difference? RFC 2616 doesn't seem to be very helpful here.
Would it be appropriate to use this to list the actions that a resource supports in a non-REST-API environment? For example, if my ConversionController supports the action convert, would a response like this make sense:
Request:
OPTIONS /conversion HTTP/1.1
Response:
HTTP/1.1 200 OK
...
Allow: CONVERT
...
RFC 2616 defines "Allow" (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7). "Public" is not in use anymore. "Access-Control-Allow-Methods" is defined in the CORS specification (see http://www.w3.org/TR/cors/).
What is an HTTP OPTIONS request?
It is a request from the client to know what HTTP methods the server will allow, like GET, POST, etc.
Request
The request might look like this when asking about the options for a particular resource:
OPTIONS /index.html HTTP/1.1
or like this when asking about the server in general:
OPTIONS * HTTP/1.1
Response
The response would contain an Allow header with the allowed methods:
Allow: OPTIONS, GET, HEAD, POST
Why is the server receiving an HTTP OPTIONS request?
Some REST APIs need it (but if you are defining the API, you'd know that)
Browsers send it to servers as "preflighted" requests to see if the server understands CORS
Attackers send it to get more information about the API
How to respond to an HTTP OPTIONS request?
You could respond with an Allowed header and even document your API in the body.
You could respond with additional CORS defined Access-Control-Request-* headers.
You could respond with 405 Method Not Allowed or 501 Not Implemented.
How do I stop getting HTTP OPTIONS requests?
If it's coming from a browser then update your API so that it isn't doing anything "dangerous" (like PUT or DELETE, or POST with application/json). Only perform simple requests.
See also
RFC 2616 Section 9: Method definitions
MDN Web docs: OPTIONS
MDN Web docs: Cross-Origin Resource Sharing (CORS)
CORS - What is the motivation behind introducing preflight requests?
How to exploit HTTP Methods
In response to the title: "How to respond to an HTTP OPTIONS request?" To answer that, I'd want to know why you want to respond to an OPTIONS request? Who/what is sending you an OPTIONS request, and why? Many public servers respond with some form of "error" or "not allowed" (500, 501, 405). So, unless you're in a specific situation where your clients will be reasonably sending OPTIONS requests and expecting useful/meaningful information back (e.g., WebDAV, CORS), you probably want to respond with: "don't do that."
In terms of your question about the "OPTIONS /conversion HTTP/1.1" request: unless you know that there's some client of your server, a client which would send an OPTIONS request to "/conversion" and expect a response with "Allow: CONVERT," the answer is no: it wouldn't make sense to respond like that. I think that most implementations that do support OPTIONS and respond with "Allow," respond with standard HTTP methods.
Here's a great article on the topic.
Summary: OPTIONS is immediately problematic because it doesn't support caching. Alternatives: server-wide metadata: try well-known URI's. Resource-specific: try using a Link header on its responses, or a link in the representation format for that resource.
Lastly, if what you're after is a service description, have a look at WADL or RSDL.
EDIT:
dotnetguy makes a good point in the comment below: OPTIONS is undeniably valuable in certain contexts (e.g., CORS); I certainly didn't mean to suggest otherwise.