I'm running Rails 3.1 with PhusionPassenger and NGINX in the back. I'm sending requests via a simple HttpClient (GrahpicalHttpClient for OS X). My code expects a token and an ID in the header to verify the authenticity of the caller. In developement mode this is no problem, but once I move it into production the header variables go missing. Nothing is displayed.
Here is the code:
#caller = Person.check_authentication_token(request.headers['person_id'], request.headers['authentication_token'])
The method check_authentication_token returns nil if either variable is nil. As I said, this works fine in development but the request.headers['person_id'] and request.headers['authentication_token'] are both nil in production. Has anyone else seen this issue before?
Nginx defaults to considering underscores in request headers invalid and subsequently removes them, see http://wiki.nginx.org/HttpCoreModule#underscores_in_headers for how to fix this.
Related
I'm currently working on the acknowledge receipt response used in SagePay on my website. I've noticed you can do things such as invoke components, read and output variables, but it doesn't allow you to set variables - even if those variables already exist. Is this the case with all HTTP requests or am i simply doing something wrong? My first thought would be if it can execute server side script then surely setting variables (session i must state - not local) should not be an issue.
We are getting a 405 error and the following exception from IIS7 when attempting to apply a ResponseStreamFilter to HttpResponse.Filter:
HttpException:
The HTTP verb POST used to access path '/app/Thing.asmx/Command' is not allowed.
We are applying the filter by using an HttpModule with code like this:
var rfs = new ResponseFilterStream(HttpContext.Current.Response.Filter);
rfs.TransformStream +=
new Func<System.IO.MemoryStream, System.IO.MemoryStream>(ProcessStream);
HttpContext.Current.Response.Filter = rfs;
Log("Response stream filter applied correctly.");
All of the code in our HttpModule works just fine... it's all wrapped in a try-catch just to be safe and isn't throwing any exceptions, and diagnostic logging like the last line above is working correctly.
But it looks like our ProcessStream method in the above code is never being called. If we apply the filter to HttpResponse.Filter at all, IIS throws the 405 exception before our filter begins processing.
Our code has worked before on several similar systems, so we suspect IIS/machine configuration on this specific server is responsible. What could be causing this?
The most commonly reported cause for a 405 error in a situation like this seems to be using Url.Rewrite. (The HTTP verb POST used to access path '/test.html' is not allowed) However, we are never using a Url.Rewrite.
Another commonly reported cause is trailing slashes in the request URL. (HTTP 405 on Error on HTTP POST IIS ASP .NET) But as mentioned above, the URL being requested does not end with a slash.
The app pool is running .NET 4.0 in a Classic pipeline (jQuery AJAX post receives 405 error (HTTP verb POST not allowed)), but our code has run without issue on many other systems under a Classic app pool, so there would still have to be something unique to this server's configuration. Changing to Integrated pipeline breaks the application our code is filtering, so that's not a possible workaround anyway.
Turns out, it was a very obscure IIS bug:
http://support.microsoft.com/kb/980368
The ExtensionlessUrl handler (*.) was incorrectly getting involved with the request instead of just the WebServiceHandlerFactory (*.asmx) as expected. The workaround was:
Manually deleting the ExtensionlessUrl handler entries from the web application's handler mappings
Manually moving the ExtensionlessUrl handler entries under anything you actually expect to be hit
Adding a web.config entry under system.webServer/handlers to remove the ExtensionslessUrl handler as needed (we went with this option to make sure it got included with app demployment)
We had to burn a Microsoft support ticket on this one, since there's no way we would have figured this out in any reasonable timeframe. Hopefully this helps someone else.
I am writing a Drupal 7 module which is listening for HTTP POST messages to be sent by a 3rd party remote application. For testing I am sending messages using the Firefox Poster extension.
If I POST the message, the following code fails to place any value in my local vars (I get 'undefined index'):
$transId = urldecode($_POST['c2s_transaction_id']);
However, if I send the message using GET, the vars get populated fine with the following code:
$transId = urldecode($_REQUEST['c2s_transaction_id']);
This is true on both my local WAMP setup and on a shared hosting package.
I have never worked with HTTP POST messages before and have no idea where the problem might be. Could it be Drupal, the web server, or my code? Can anyone suggest how I might resolve this?
Many thanks,
Polly
Drupal removes the $_POST/$_GET in the system, just use $_REQUEST instead.
I am trying to implement an OAuth provider in Rails 3. When I try to authorize a client app I get this error. I am using the RESTful auth plugin and pelles OAuth-plugin. When I was testing via the Rails console and getting this error I thought that I simply needed to encode the URLs but I get the same error when testing in browser so I am not sure what is wrong.
I got into trouble with URI.split (returning this error), I don't know if this helps you, but I will post here some warnings for also someone else having this error:
Check your url is not nil, and it's a valid one.
Do URI.encode(url) before URI.parse (to avoid special characters)
Do strip to the string you pass to URI.parse (to avoid leading and trailing whitespaces).
All in one:
uri = URI.parse(URI.encode(url.strip))
Related resource: http://www.practicalguile.com/2007/09/15/raising-uriinvalidurierror-from-a-perfectly-valid-uri/
You can also use this alternative URI gem: https://github.com/sporkmonger/addressable
There is no such problems with it.
Very native, just add namespace in your code after installing the gem
Addressable::URI
try this:
safeurl = URI.encode(url.strip)
response = RestClient.get(safeurl)
I'm here because I faced an issue with the fastlane. It's been written with Ruby thus my answer can be helpful.
In my case, I had the environment variables http_proxy = XX.XX.XX.XX:XXXX and https_proxy = ...
When I changed them to http_proxy = http://XX.XX.XX.XX:XXXX and https_proxy = https://... respectivle the issue has gone.
I have a WCF service that among other bindings also uses WebHttpBinding for JSON inputs/results.
I made a custom IErrorHandler implementation in order to be able to set the StatusCode to 400 when something goes wrong and also return a JSON understandable message. It´s the straight implementation that you can find everywhere (nice way described here).
My problem is: when I test it locally using Visual Studio Web Development Server (Cassini) it works perfectly. However, when I deploy it to my test server (Windows 2008 with standard config for IIS and everything else) it does not work.
When I call it and debug with Firebug I get a HttpStatusCode 200 as a return and no response text. With Fiddler I get a HttpStatusCode 504 and no return at all. However, the behavior I expected (and what happens locally) is a call to the error callback of the ajax call with the responseText set.
I debugged it remotely and everything looks just fine. The execution pipeline is OK and all the classes are called as they should be just like they are locally, except it does not work.
Any suggestions? I´m pretty much out of options here to figure this out.
Thanks a lot!
if firebug and fiddler are giving different results, what happens if you telnet to it directly and perform a request (Something like:)
GET /VirtualDirectoryAndGetData HTTP/1.1
HOST: example.com
[carriage return]
It wouldn't surprise me if you're somehow getting odd headers/formatting back (to explain why firebug/fiddler disagree)
Another thing to test would be publishing to your dev machine to see if it's a machine-specific issue or a server vs dev webserver issue.
If it's happening anywhere outside VS, you might also try commenting out the lines where you set
rmp.StatusCode = System.Net.HttpStatusCode.BadRequest;
rmp.StatusDescription = "Bad request";
This may indicate whether it's a response code issue or an error handler issue.
If you can edit your question to include the results (with sensitive info removed), we'll see if we can track it down further.
Edit: after looking at the question again, it may well be that the server is erroring before it can send ANY response. FF might assume 200 by default, whereas ie might assume 504 (Gateway Timeout). This is total speculation but is possible. Do you see anything in the event logs?
I had a similar issue which I was able to solve. Take a look at the IIS settings. Details on how I overcame the issue are in this post: IErrorHandler returning wrong message body when HTTP status code is 401 Unauthorized