I have a basic silex application, and I try to test it using HTTPie. Yet when posting using:
http POST http://localhost:1337 data="hello world"
The data, that I get from the Request object via:
$data = $request->request->get('data');
will always be empty. What is the problem here?
It was an httpie usage problem as the form flag was necessary, as silex requires the parameters to be form-encoded, yet the default of HTTPie is to pass a JSON object.
$ http --form POST http://localhost:1337 data="hello world"
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: close
Content-Type: application/json
Date: Wed, 14 Oct 2015 15:04:09 GMT
Host: localhost:1337
X-Powered-By: PHP/5.5.9-1ubuntu4.13
{
"message": "hello world"
}
Just to clarify what kOpernikus said, when you are making a POST request using httpie, use the following syntax:
http --form post :3000/register username="gilbert" password="stackoverflow!"
Alternatively, since forms are for post requests you can leave out post and also abbreviate --form to -f like so:
http -f :3000/register username=gilbert password=stackoverflow!
EDIT (thanks to Aerials)
To pass csrf token as header in the post request do:
http --form POST http://localhost:8000/login/ username=user password=pass X-CSRFToken:assQ$%auxASDLSIAJSd
Related
I want implement this answer in Kemal.
My current setup has a pdf file in app/public/map.pdf, and the following code in my main crystal file:
require "kemal"
#...
get "/map.pdf" do |env|
env.response.headers["Content-Type"] = "application/pdf"
env.response.headers["Content-Disposition"] = %(inline;filename="myfile.pdf")
end
Kemal.run
When I test my code by opening localhost:3000/map.pdf in a browser (firefox), it prompts to download the file (while I want it to attempt to display it). And curl -I results in the following:
HTTP/1.1 200 OK
Connection: keep-alive
X-Powered-By: Kemal
Content-Type: application/octet-stream
ETag: W/"1494983019"
Content-Length: 1170498
Where I would hope to see Content-Type: application/pdf.
Kemal author here,
If the headers are ok you should be good to go with send_file. However be sure that the route name and file are not the same. In this case the route is /pdf
get "/pdf" do |env|
env.response.headers["Content-Type"] = "application/pdf"
env.response.headers["Content-Disposition"] = %(inline;filename="map.pdf")
send_file env, "./public/map.pdf"
end
Where I would hope to see Content-Type: application/pdf.
The point is that Content-Disposition doesn't exist as a header.
Maybe you don't send any headers at all for some reason.
For example in PHP, if your script outputs a single byte before it sends the headers then no headers will be sent; only the headers before the first output.
If you set a http header after some data is sent then the header will be ignored.
According to the documentation and some similar questions on SO curl should follow a redirect using GET method, unless --post30x is specified as a parameter. However that's the result of my testing
curl -kvv -b /tmp/tmp.BEo6w3GKDq -c /tmp/tmp.BEo6w3GKDq -X POST -H "Accept: application/json" -L https://localhost/api/v1/resource
> POST /api/v1/resource HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost
> Cookie: JSESSIONIDSSO=AB59F2FD09D38EDBAACB726CF212EA2E; JSESSIONID=743FD68B520840094B6D283A81CF3CFA
> Accept: application/json
>
< HTTP/1.1 302 Found
< Server: Apache-Coyote/1.1
< Strict-Transport-Security: max-age=15768000; includeSubDomains
< Cache-control: no-cache, no-store
< Pragma: no-cache
< Location: https://testserver.int/api/v1/resource
< Content-Length: 0
< Date: Fri, 27 Jan 2017 08:41:05 GMT
<
> POST /api/v1/resource HTTP/1.1
> User-Agent: curl/7.29.0
> Host: testserver.int
> Cookie: JSESSIONID=1tcxpkul4qyqh1hycpf9insei9
> Accept: application/json
I would expect the second request to actually be using GET instead of POST.
curl's man page says:
When curl follows a redirect and the request is not a plain GET (for
example POST or PUT), it will do the following request with a GET if
the HTTP response was 301, 302, or 303. If the response code was any
other 3xx code, curl will re-send the following request using the same
unmodified method.
You can tell curl to not change the non-GET request method to GET
after a 30x response by using the dedicated options for that:
--post301, --post302 and --post303.
Unfortunatelly that's not what I'm seeing and there is no option for --get30x.
So my question is - how to make curl follow a redirect response (301/302/303) with a GET request to the Location as it is written in the documentation?
I've tested it with curl/7.29.0 as well as curl/7.50.3.
Problem: You are telling curl to do that with your use of -X POST. As the man page section for -X explains this:
The method string you set with -X, --request will be used for all requests, which
if you for example use -L, --location may cause unintended side-effects when curl
doesn't change request method according to the HTTP 30x response codes - and
similar.
Fix: Remove the -X POST from your command line. Use -d "" instead to send an empty post that will adjust accordingly to the proper method after redirect.
More: Explanation and rant in my blog post unnecessary use of curl -X.
I'm creating a simple web server using Go's http package. I'm registering just one handler, for requests to the path "/requests/".
It can handle GET requests just fine but when I send a POST request, the handler is never invoked and the client gets a 301 Moved Permanently response.
I've tried searching for this but it appears this isn't a problem people are commonly facing.
My handler is:
func requestHandler(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello")
}
main function:
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/requests/", requestHandler)
http.ListenAndServe(":8000", mux)
}
Curl gives the following output:
>> curl -i -X POST http://localhost:8000/requests
HTTP/1.1 301 Moved Permanently
Location: /requests/
Date: Thu, 12 Jan 2017 08:51:10 GMT
Content-Length: 0
Content-Type: text/plain; charset=utf-8
Go's own http client returns a similar response object:
&{301 Moved Permanently 301 HTTP/1.1 1 1 map[Content-Type:[text/plain; charset=utf-8] Location:[/requests/] Date:[Thu, 12 Jan 2017 08:51:58 GMT] Content-Length:[0]] 0x339190 0 [] false false map[] 0xc4200cc0f0 <nil>}
Again, GET requests behave just as I'd expect them to and invoke the handler function. Do I need to do something differently to handle POST requests? Thanks for any help on this!
You are querying for /requests.
The redirect is pointing you to /requests/
You used curl like this :
curl localhost:8000/requests
You need to either use /requests instead of /requests/ in mux.HandleFunc.
or use
curl localhost:8000/requests/
Also note that if you request would work on a browser without any change as it handles redirects automatically.
And the route with trailing slash would return 404, if the route in mux.HandleFunc does not have a trailing slash.
PS : Your requestHandler handles all methods, not just POST requests. You need to check for r.Method to handle the methods differently.
In the HTTP language, the following lines expresses a GET request on a collection of articles:
GET /articles HTTP/1.1
Accept: application/json; level=1
Host: example.com
However, in this language, how can we express a request through a POST with its data? Is there an official spec? Thank you.
Edit
Using curl, a such request could be:
curl -H 'Accept: application/json; level=1' \
-X POST \
-d '<json>' \
http://example.com/articles
...where <json> could be:
{
"article": {
"title": "foo"
}
}
This example can be a POST with an empty body since your request is composed only of HTTP headers. But I don't recommend this.
You can read about HTTP in the RFC
Given this snippet:
(defroutes main-routes
(POST "/input/:controller" request
(let [buff (ByteArrayOutputStream.)]
(copy (request :body) buff)
;; --- snip
The value of buff will be a non-empty byte array iff there's the Content-Type header in the request. The value can be nonsencial, the header just has to be there.
However, I need to dump the body (hm... that came out wrong) if the request came without a content type, so that the client can track down the offending upload. (The uploading software is not under my control and its maintainers won't provide anything extra in the headers.)
Thank you for any ideas on how to solve or work around this!
EDIT:
Here are the headers I get from the client:
{
"content-length" "159",
"accept" "*/*",
"host" (snip),
"user-agent" (snip)
}
Plus, I discovered that Ring, using an instance of Java's ServletRequest, fills in the content type with the standard default, x-www-form-urlencoded. I'm now guessing that HTTPParser, which supplies the body through HTTPParser#Input, can't parse it correctly.
I face the same issue. It's definitely one of the middleware not being able to parse the body correctly and transforming :body. The main issue is that the Content-Type suggest the body should be parsable.
Using ngrep, I found out how curl confuses the middleware. The following, while intuitive (or rather sexy) on the command line sends a wrong Content-Type which confuses the middleware:
curl -nd "Unknown error" http://localhost:3000/event/error
T 127.0.0.1:44440 -> 127.0.0.1:3000 [AP]
POST /event/error HTTP/1.1.
Authorization: Basic SzM5Mjg6ODc2NXJkZmdoam5idmNkOQ==.
User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3.
Host: localhost:3000.
Accept: */*.
Content-Length: 13.
Content-Type: application/x-www-form-urlencoded.
.
Unknown error
The following however forces the Content-Type to being opaque and the middleware will not interfere with the :body.
curl -nd "Unknown error" -H "Content-Type: application/data" http://localhost:3000/event/error
T 127.0.0.1:44441 -> 127.0.0.1:3000 [AP]
POST /event/error HTTP/1.1.
Authorization: Basic SzM5Mjg6ODc2NXJkZmdoam5idmNkOQ==.
User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3.
Host: localhost:3000.
Accept: */*.
Content-Type: application/data.
Content-Length: 13.
.
Unknown error
I'm considering replacing the middleware with a more liberal one because even though the request is wrong, I'd still like to be able to decide what to do with the body myself. It's a really weird choice to zero the request body when the request doesn't make sense. I actually think a more correct behavior would be to pass it to an error handler which by default would return a 400 Bad Request or 406 Not Acceptable.
Any thoughts on that? In my case I might propose a patch to Compojure.
According to:
http://mmcgrana.github.com/ring/ring.middleware.content-type-api.html
the default content type is application/octet-stream. Unless you actively support that content type, can't you just check if the content type matches that one, and then dump whatever you need based on that?