0

An issue we've faced since the beta launch of our software is that not all of our users are able to be authenticated (we authenticate using web requests) as a result of something happening. We're not sure exactly what is causing it, but we're slightly confident that it's caused by our POST requests. Below is the C# method we use to do the request.

public static string getResponse(string url, string postdata)
{
    try
    {
        ASCIIEncoding encoding = new ASCIIEncoding();
        byte[] byte1 = encoding.GetBytes(postdata);
        HttpWebRequest myHttpWebRequest = (HttpWebRequest)WebRequest.Create(url);
        myHttpWebRequest.Method = "POST";
        myHttpWebRequest.ContentType = "application/x-www-form-urlencoded";
        myHttpWebRequest.ContentLength = byte1.Length;
        Stream newstream = myHttpWebRequest.GetRequestStream();
        newstream.Write(byte1, 0, byte1.Length);
        WebResponse response = myHttpWebRequest.GetResponse();
        Stream stream = response.GetResponseStream();
        StreamReader reader = new StreamReader(stream);
        return reader.ReadToEnd();
    }
    catch
    {
        return "";
    }
}

Perhaps we haven't structured it in a way that all firewalls will accept it, for example.

With that said, we do not know if it's the issue of the port, the request itself, or the user's issue. Has anyone ever faced this issue before? What did you do to fix it?

Are there "standards" to how you structure your POST so most devices/firewalls will accept it? Are we using the right port?

theGreenCabbage
  • 5,197
  • 19
  • 79
  • 169
  • The port should default to port 80 or 443 depending on the `url` string. If the `url` is using a non-standard port then you might have firewall issues. – Dustin Kingen Feb 05 '14 at 20:43
  • Have you tried watching what happens when you send this request from e.g Fiddler? What response are you getting back? – Stephen Byrne Feb 05 '14 at 20:44
  • Hi @Romoku, is `url` where you specify your port? Since port 80 or 443 are default ports, could I just hardcode the ports in so they're successful everytime? @StephenByrne What are some things I should notice when looking at the response headers? – theGreenCabbage Feb 05 '14 at 21:13
  • 1
    Well you're looking for anything out of the ordinary - HTTP 500, 401, 403 etc, anything that would indicate that the request is failing on the server. Or timeouts to indicate the request is being blocked ,etc – Stephen Byrne Feb 05 '14 at 21:26
  • @StephenByrne That is a very elegant solution! Is there anything the user on their end could tell me what error code they give me? Perhaps in my software I could add onto the existing debugger that'll print these HTTP errors? – theGreenCabbage Feb 05 '14 at 21:28
  • Also, I've done some Googling regarding a "standard" on how to create successful HTTP requests, but I couldn't really find anything other than companies advertising their services. Are there any sites like perhaps from W3C that could give me a better idea? – theGreenCabbage Feb 05 '14 at 21:29
  • Well the `HttpWebRequest` class will create correctly formed HTTP requests for you, I don't think this is your issue. For handling errors in the response, see here: http://stackoverflow.com/questions/7609194/how-to-process-webresponse-when-net-throws-webexception-400-bad-request – Stephen Byrne Feb 05 '14 at 21:31
  • Hi Stephen. I have posted an answer. Would my answer work without Fiddle? Since we're catching Web Exceptions. – theGreenCabbage Feb 05 '14 at 22:08

1 Answers1

0

I have updated my catch statement to catch Web Exceptions:

catch (WebException ex)
{
    ex.writeToDebuggerOrTxtFile;
}

Since at the moment we are not entirely sure about what is causing the issue, that is, we don't know if it's the user, firewall, or ports, that's causing the user being unable to authenticate, we have to first isolate the issue. If the status codes return something like HTTP 500, 401, 403, etc, then this indicates that the request is failing on the server.

EDIT: Upon sleeping over this, I saw a bit of an issue with this answer.

Let me explain.

Generally, all HTTP responses should succeed, even if the status code may return a code that indicates an error. I think the right way to approach this is to simply not just look at the WebExceptions thrown (since most "failed" responses should return a success), but to also look at purely the status codes.

A failed response would still succeed in bringing a response headers back, but the right way to approach it, I think, is to look at the status codes themselves.

Here's a node.js script I whipped up to check HTTP response headers:

var http = require("http");

var fs = require("fs");
var i = 0;

var hostNames = ['www.google.com'];

for (i; i < hostNames.length; i++){

    var options = {
            host: hostNames[i],
            path: '/'
    };

  (function (i){
    http.get(options, function(res) {

      var obj = {};
      obj.url = hostNames[i];
      obj.statusCode = res.statusCode;
      obj.headers = res.headers;

      for(var item in res.headers){
        obj.headers[item.replace(/\./,'\\')] = res.headers[item];
      }

      console.log(JSON.stringify(obj, null, 4));

    }).on('error',function(e){
      console.log("Error: " + hostNames[i] + "\n" + e.stack + "\n");
    });
  })(i);
};
theGreenCabbage
  • 5,197
  • 19
  • 79
  • 169