-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[0.12 / master] POST to /write does not write points if request has header 'Content-Type: application/x-www-form-urlencoded' #6061
Comments
@mark-rushakoff Try replacing calls to |
@joelegasse Yep, that fixes it. There's a few other uses of Any thoughts on |
@mark-rushakoff I like the idea of returning the points written and a custom header seems like appropriate. How about a |
FormValue() would attempt to parse the body of a request when the content-type is set to `application/x-www-form-urlencoded`. The write handler never wants url-encoded forms, and should only ever check the URL for query parameters. Fixes #6061
it would be nice if it was specified what Content-Type should be for posts... I'm searching all over and I can't find any mention of it aside what it should not be... |
@ReinsBrain I agree. It took me so long to get it to send data to the database and now no data is being written. I keep getting "No Content Found" errors. It's sad that the documentation of the HTTP API is so poor. |
tl;dr: POST to /write with
Content-Type: application/x-www-form-urlencoded
appears as a request with an empty body to thehttpd
service. The client can't distinguish between a response where no points were written and a response where all points were successfully written.I'm working from d61d75f and I've made the following modifications to my working tree while debugging why my writes have been silently failing:
First, a write via curl like the examples show:
A 204 response here implies to the client that all the points have been written successfully, but
SELECT * FROM tmp
returns no results, and the manually added log shows that the HTTP server did not see any points because it detected an empty request body:Repeating the same curl command with the addition of a Content-Type header:
The HTTP log now indicates there was a point present and that the request body was not empty:
Inserting a point via the
influx
CLI still works, apparently because it sets Content-Type header to an empty string:There are at least two issues here:
Content-Type: application/x-www-form-urlencoded
is a regression from previous behavior. That Content-Type is almost certainly the wrong one to use, but it's the default for most HTTP clients' POSTs if the user doesn't specify otherwise, so it seems important that InfluxDB accepts line protocol with that header. (I dug through net/http source for a bit but wasn't able to conclude anything; it might be related to the early call to(*http.Request).FormValue()
before evaluating(*http.Request).Body
. This blog post might also be a pointer in the right direction.)X-Influxdb-Points-Written: 123
would allow the client to confirm that the request completed as expected.The text was updated successfully, but these errors were encountered: