I am trying to send data from an arduino to a web server (LAMP) using the ESP8266 module, when I do a POST to a local network server the server receives the data and returns 200, however, when I post to an external server
(Hosting or google cloud) it registers error 400 in the Apache log and returns nothing, but when I do the same type of request by Postman everything is fine, because of this I do not know if it is my fault when mounting or executing the request or if Is some block on the external servers because the http server in my network works.
I'm using this lib to work with ESP: https://github.com/itead/ITEADLIB_Arduino_WeeESP8266
This is the request string:
POST /data/sensor_test.php HTTP/1.1
Host: xxxxxxxxx.com
Accept: */*
Content-Length: 188
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
temperatureAir1=19.70&humidityAir1=82.30&temperatureAir2=19.40&humidityAir2=78.60&externalTemperature=19.31&illumination05=898&illumination10=408&humiditySoilXD28=6&humiditySoilYL69=5
I found the problem, when I concatenated the strings that make up the request I was doing line breaks with \n, I switched to \r\n and it worked!
The amount of bytes really is with error, I am seeing to correct, but the good thing is that now the request is right.
Related
I have a Windows application that makes a POST request using WinHTTP. It sends some custom headers and a CSV file in the body of the request.
It has been working fine when sending the request to localhost (http://127.0.0.1), but the remote server returns Status 500 - Internal Server Error.
However, the exact same request made via Postman to the remote server returns Status 200 - OK.
I have copies of the headers being sent from both applications. The only difference I can see is that, when sending via Postman, the value of Content-Length is always 20 greater than the header sent using WinHTTP. This is regardless of the actual size of the file, so the difference is always the same.
I don't know if this is to do with the way each application parses the CSV file, but neither is being zipped or anything like that.
If I manually change the value of Content-Length in Postman to match that being sent by WinHTTP, it throws the same 500 error, so I can actually replicate the error by bodging the value of Content-Length.
Therefore, I can only presume that the 500 error is being caused by a dodgy Content-Length header being generated by WinHTTP.
No data is being sent before the headers. There are no overly useful logs on the server, only the fact that an internal server error was thrown and the date/time it happened.
Is this problem likely to lie with WinHTTP, or is there a server configuration that needs to be changed?
I am unable to understand why one method returns 200 - OK and the other 500 - Internal Server Error, except for something to do with the Content-Length header.
I'm trying to debug an issue calling the Twitter API (it works on my localhost, but doesn't work from a Server 2012 R2 build). But i don't think it's an issue on Twitter's side.
Anyway, to strip it down to a basic example, if i use Fiddler on my local Windows 10 desktop to POST to this endpoint: https://api.twitter.com/oauth/request_token
With this header data:
User-Agent: Fiddler
Authorization: OAuth oauth_consumer_key="xx",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1654005734",oauth_nonce="yy",oauth_version="1.0",oauth_signature="zz"
Accept: */*
Host: api.twitter.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 0
I 'successfully' receive a HTTP 401, which is expected (because the info in my request is obviously inaccurate for this forum). Great.
But if i POST the exact same data using Fiddler on my Server 2012 R2 build, I get an HTTP 404?
Can anybody explain why this might be? I don't see any errors in Wireshark related to certificates or ciphers? I'm stumped....
UPDATE
I can reproduce the same issue with PowerShell like so:
Invoke-WebRequest -Headers #{"Authorization" = 'OAuth oauth_consumer_key="xx",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1654005734",oauth_nonce="yy",oauth_version="1.0",oauth_signature="zz"' } `
-Method POST `
-Uri https://api.twitter.com/oauth/request_token
I've finally got it working after days of debugging. It has something to do with Schannel/TLS/Cipher suites, but I'm not exactly sure what the specific fix was. I hope this helps somebody and saves a few days of pain.
https://www.alkanesolutions.co.uk/2022/06/07/twitter-api-giving-http-404-not-found-when-requesting-a-token/
I'm attempting to get my App-Only bearer token from the Twitter Oauth2 API. Depending on how I do it, I get either error 400 (Bad Request) or 503 (Service Temporarily Unavailable). I'm stumped.
Attempt 1 was via a HTTPS socket (in Xojo, if you must know); when that failed I dropped down to a raw SSL socket, so that I know exactly what I'm sending. I'm sending this (with the credentials ellided here):
POST /oauth2/token HTTP/1.1
Host: api.twitter.com
User-Agent: My Twitter App v1.0.23
Authorization: Basic MUs1NGpvd (...stuff deleted...) MmpxeQ==
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Content-length: 29
Accept-Encoding: gzip
grant_type=client_credentials
This request is modeled directly after the one in the docs. It produces a 400 (Bad Request) error code.
Then I decided to try curl (again, credentials ellided):
curl -i -d 'grant_type=client_credentials' -H 'Authorization: Basic MUs1NGpv (...blah blah...) mpxeQ==' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' 'https://api.twitter.com/oauth2/token'
And this produces a 503 status code every time.
My credentials are just the Base64 version of my API key and secret, joined by a colon. The same key and secret work fine when tested with STTwitterDemoOSX. I'm almost (but not quite) desperate enough to use WireShark to see what that app is sending. But there must be something simple I'm doing wrong. Any ideas?
Oops. I found the problem, at least with the curl attempt: somehow a line break snuck into my authorization string without my noticing. When I take the line break out, it works.
Apologies for the noise (but maybe this will help someone else someday).
everyone:
I have this nagging problem I cannot seem to fix. So, please, help me out!!!!
So, I have a page that renders a partial. The page gets renders correctly within a couple of seconds, however, Chrome still receives (by showing the "loading" icon") for some 30 more seconds and reports an error (failed to load resource) on Chrome Inspector. It seems like the response is not correctly closed. If I took out the line in the partial, that renders asian characters, it would work fine - meaning it would render the page and properly stops.
This problem gets worse, if the partial is gets rendered as part of an AJAX call via jQuery. It would not even get rendered then, because it fails to get a proper ending for the response.
I would appreciate your help.
Thanks.
Here is the HTTP header:
Request Method:GET Status Code:200 OK Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch Accept-Language:en-US,en;q=0.8
Connection:keep-alive Cookie:XXXXX Host:localhost:3000
Referer:https://localhost:3000/home User-Agent:Mozilla/5.0 (Macintosh;
Intel Mac OS X 10_7_2) AppleWebKit/535.2 (KHTML, like Gecko)
Chrome/15.0.874.106 Safari/535.2 Response Headersview source
Cache-Control:max-age=0, private, must-revalidate
Connection:Keep-Alive Content-Length:55118 Content-Type:text/html;
charset=utf-8 Date:Wed, 02 Nov 2011 23:07:52 GMT
Etag:"77d774b3b119012c5fabbd5c625a98a8" P3p:CP="CAO PSA OUR"
Server:WEBrick/1.3.1 (Ruby/1.9.2/2011-07-09) OpenSSL/0.9.8r
X-Runtime:1.070787 X-Ua-Compatible:IE=Edge
UPDATE:
I just installed Firefox/Firebug. They give more info than Chrome does. What a pleasant surprise! Firebug confirmed my theory that somehow content-length got messed up. So, if the rendered partial contains some asian characters, the content-length in the response header and the actual response body size are different. If no asian characters are present, they are the same. Has anybody seen this problem before?
OK! We finally figured this out! YEAAAAH!!!
This was caused by WEBrick's inability to handle HTTPs correctly. Basically, WEBrick would not render pages correctly, which would causes a discrepancy between Content-Length in the response header and the actual body size. When this happens, the browser would wait for request to complete and throws an error (usually Failed to load resources error on Chrome) after 30 some seconds.
So, if you want to use HTTPs on your machine (localhost), make sure you use Thin as your server and nginx as a reverse proxy server. Even though it sounds complicated, it's not. Basically, Thin will serve up your pages just like how WEBrick would do. If a HTTPS request comes in, say through port 443 or whatever port you set up for, nginx takes care of validating the request and forwards it to Thin, which then handles the rendering, etc.
I hope this posts would help someone..
I have a REST API in Rails 3 being accessed sometimes from an AIR application and sometimes from the browser.
I think this is a Rails 3 problem but it might be a Flex/AIR problem.
The Rails app uses omniauth for authentication, cancan for authorization, and active_record_store. I use the session model to store the identity of the user.
(There is a reason I'm not using cookie sessions, having to do with AIR for Android, OAuth, and StageWebView.)
I'm using Charles to monitor HTTP traffic.
Most requests work fine. The browser (or the AIR client) sends the session ID to the server using the Cookie http header, like this:
_session_id=950dee7eca6732aa62b5f91876f66d15
And Rails finds the session, figures out who the user is, and does its thing.
But under certain circumstances, Rails generates a new session before sending the response. It adds a session to the sessions table, and returns a Set-Cookie header to the client with a new session ID. Like this:
_session_id=e1489a6b610c0a1d13cec1454228ae47; path=/; HttpOnly
The circumstances under which this happens are:
The request comes from the AIR client
The request is a POST
This is obviously a problem, because on subsequent requests, Rails can't find the user information. It created a new session without that information.
So I'm looking at the HTTP headers for the POST request. Here's a copy/paste from Charles; I inserted the colon after the header name to make it readable.
Host: localhost.seti.hg94.com:3000
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/531.9 (KHTML, like Gecko) AdobeAIR/2.6
Referer: app:/AndroidApplication.swf
X-Flash-Version: 10,2,152,22
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Cookie: _session_id=950dee7eca6732aa62b5f91876f66d15
Content-Length: 84
Connection: keep-alive
Does anyone have any insight into why Rails would generate a new session under those circumstances? It seems to be happening after my controller code executes, since I have the correct session information in the controller.
I'm busy trying to isolate the problem further, control the headers from within AIR, and so on. I've been working on this bug for almost a week. So any insight or suggestions from the community would be greatly appreciated.
Only a guess, but it seems like you're not bringing across the CSRF token that Rails generates for all POST-based requests:
http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf