While doing some tests against some endpoints I noticed that on the put /users/:user/follows/channels/:target endpoint I get a 411 error length required. This happens in curl as well if you don’t do -H “Content-Length: 0” I am not big on http so I am just asking if this is a bug or just how the PUT method is called? I have changed my code to add the content-length: 0 header in when the PUT method is used and if there is no data in the data param.
Random question. In the API TOS #13-a Is there any place where I can go to see if my app is behaving correctly? I am writing code with very little libraries and so I have to handle everything myself. Although I do test against a local server I just want to make sure that a bug on either end doesn’t violate that 13-a rule. Also other than here is there a place to get #8 done?
I would rather be for sure everything is safe before I go about and ignore stuff for days on end.
I’ve seen the same “issue” with PUT I did the same and didn’t worry about it, as it fitting in nicely with my abstraction. PUT can be a toss up in HTTP parlance as generally you would be PUTting data in the body rather than just “query string” as is the case here. (I’ve not looked into it but it could be a hiccup in Nginx itself strokes beard thoughtfully)
Regarding 13a, there is no where to go and have a look, but I have read elsewhere that if there is a issue with your application that violates 13a they’ll get in contact fairly quickly. Just make sure you are not hammering too often too hard and caching where you can.
Really if you think you are hitting too hard to violate, you need to reassess your applications behaviour.
Really not too worried about hammering the endpoints. I will be coding in my own rate limits when the final product is just unleashed. I am more worried about not conforming to some standard absolutely 100% and causing weird things to happen.
I am still looking up everything I can for http like just a few minutes ago with the delete block endpoint. I had no handle for 204. Thus leaving my socket to stay open till the server disconnected. That gave me a big fat error because I was parsing data/rest of the function on completion of data either from content-length or transfer-encoding. So I am now checking for status codes now as well. WOOT
We made some internal changes to PUT /users/:user/follows/channels/:target last week, so if you’re just noticing this recently, thanks for bringing it up – it’s likely a bug. afaik you should not be needing to specify Content-Length: 0 to get a 200 back. I’ll look into what could be causing this.
Okay cool, I guess I was testing locally without realizing it. I can reproduce now.
The 411 is being produced by nginx before ever getting to Rails. After some investigation, it turns out that this is the correct behavior. From the HTTP/1.1 4.4 spec, on Message Length:
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length.
curl seems to automatically specify a Content-Length for you if there’s a message-body present (to see this, try replacing -H 'Content-Length: 0' with just -d ''). But if there’s not one, you’ll have to do it manually.
Hope this helps.
EDIT: Yeah @BarryCarlyon basically hit the nail right on the head.