11

In Delphi, I'm using Indy's TIdHTTPWebBrokerBridge coupled with TIdHTTP to send/receive data via HTTP. On the Server, I don't have any fancy handling, I always just respond with a simple content stream. If there's any issues, I only return information about that issue in the response content (such as authentication failed, invalid request, etc.). So, on the client side, can I assume that every successful request I make to this server will always have a response code of 200 (OK)?

I'm wondering because on the client, the requests are wrapped inside functions which return just a boolean for the success of the request.

Inside this function:

IdHTTP.Get(SomeURL, AStream);
Result:= IdHTTP.ResponseCode = 200;

This function handles any and every request which could possibly fetch data. If there were any issues in the request, This function should return False. In my scenario, since I always return some sort of content on the server, would the client always receive a response code of 200 in this function?

I guess the real question is, if I always return some sort of content and handle all exceptions on the server, then will the server always return status code of 200 to each request?

Jerry Dodge
  • 26,858
  • 31
  • 155
  • 327

4 Answers4

17

"Does every successful HTTP request always return status code 200?"

See w3.org: HTTP/1.1 Status Code Definitions (RFC 2616)

The answer is No. All 2xx are considered successful. That may depend on the HTTP method used.

Should your web-server application always return 200 upon success? That may as well depend on the request method and the signal it intends for the client . e.g.

for PUT method (emphasis is mine):

If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request.

for POST method:

The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30). Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.

As you can learn from the RCF, every method SHOULD have it's own success status codes, depending on the implementation.

Your other question:

"can I assume that every successful request I make to this server will always have a response code of 200 (OK)?"

You can always expect Status code 200, if your web server always responds with Status 200. Your web server application controls what response it returns to the client.

That said, Status code 200 is the Standard response for successful HTTP requests (The actual response will depend on the request method used), and in the real world of web servers, SHOULD be set as default upon successful request, unless told otherwise (As explained in Remy's answer).

Community
  • 1
  • 1
kobik
  • 21,001
  • 4
  • 61
  • 121
  • Thanks for the perfect explanation, but refer to Remy's answer which I just accepted rather than this, simply because it's specific to my exact scenario. – Jerry Dodge Mar 01 '13 at 00:16
  • 4
    @Jerry, NP, You should select the answer that suits you best. Remy gave you an excellent answer and got a +1 from me as well. My answer is general to ALL HTTP servers and in fact it should not matter if your client uses IdHTTP and the server is TIdHTTPServer. you SHOULD always respect the RCF no matter what. A lot of `SHOULD`s eh? :) – kobik Mar 01 '13 at 16:01
  • Yes, this type of question can be responded to with either a `SHOULD` answer or a `WOULD` answer, which both are equally right, but I was aiming for the `WOULD`. – Jerry Dodge Mar 01 '13 at 16:41
  • 3
    @Jerry, as I explained, The WOULD part is entirely up to *you* and *your* web server implementation - based on the SHOULD specs of course. – kobik Mar 01 '13 at 16:50
  • That is correct, I was just pointing out and translating what I understood you to mean. – Jerry Dodge Mar 01 '13 at 16:52
9

To answer your specific question:

can I assume that every successful request I make to this server will always have a response code of 200 (OK)?

The answer is Yes, because TIdHTTPWebBrokerBridge wraps TIdHTTPServer, which always sets the default response code to 200 for every request, unless you overwrite it with a different value yourself, or have your server do something that implicitly replies with a different response code (like Redirect() which uses 302, or SmartServeFile() which uses 304), or encounter an error that causes TIdHTTPServer to assign a 4xx or 5xx error response code.

However, in general, what others have told you is true. On the client side, you should handle any possible HTTP success response code, not just 200 by itself. Don't make any assumptions about the server implementation.

In fact, TIdHTTP already handles that for you. If TIdHTTP encounters a response code that it considers to be an error code, it will raise an EIdHTTPProtocolException exception into your code. So if you don't get an exception, assume the response is successful. You don't need to check the response code manually.

If there is a particular response code that normally raises an exception but you do not want it to, you can specify that value in the optional AIgnoreReplies parameter of TIdHTTP.Get() or TIdHTTP.DoRequest(). Or, if you are are using an up-to-date Indy 10 SVN revision, a new hoNoProtocolErrorException flag was recently added to the TIdHTTP.HTTPOptions property so the EIdHTTPProtocolException exception is not raised for any response code.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • I'm accepting your answer instead, since it's directly aimed at my exact scenario rather than general HTTP standards. The other answers, although are very true, are assuming the server is responding various different responses based on standards, but my server is not standard. In fact, I deliberately make it difficult to work with for a security measure. – Jerry Dodge Mar 01 '13 at 00:14
  • Plus you're a valuable resource because you're part of the Indy team :D – Jerry Dodge Mar 01 '13 at 00:36
2

Successful resposes are 2xx List_of_HTTP_status_codes

bummi
  • 27,123
  • 14
  • 62
  • 101
  • Yes, I'm looking at the same link, but I mean with the way I'm using it, is there a possibility I may get something other than 200? Can I assume that anything in the 2xx range is successful? All my tests return 200, I want to know the likelihood of it not being 200. – Jerry Dodge Feb 28 '13 at 20:46
  • the likelihood will depend on your planned usage, examples for not beeing 200 can be found in contexts of post and rest. e.g. http://bitworking.org/projects/atom/rfc5023.html#crwp – bummi Feb 28 '13 at 20:58
  • So the answer is that I should check just if the code is in the 200..299 range rather than just 200? – Jerry Dodge Feb 28 '13 at 21:04
  • If `TIdHTTP` encounters a response code that it considers to be an error code, it will raise an `EIdHTTPProtocolException` exception. So if you don't get an exception, assume the response is successful. You don't need to check the response code manually. However, if there is a particular response code that normally raises an exception but you do not want it to, you can specify that response code in the optional `AIgnoreReplies` parameter of `Get()` and `Post()`. – Remy Lebeau Feb 28 '13 at 22:24
  • @Remy Looking in the `Post` function and there is no overload version with a parameter `AIgnoreReplies` however I am using it in the `Get` function. – Jerry Dodge Mar 01 '13 at 16:39
  • @JerryDodge: Sorry, I meant `DoRequest()` instead of `Post()` – Remy Lebeau Mar 01 '13 at 21:04
1

i did the following. Process straight all 200`s and LOG exceptions. worked, not a single non 200 - except unauthorized and timeouts (password or sometimes unavaliable server). but many/all responses will be considered for a wide range of mainstream apps.

      while (iRedo < 3) do begin
        s := Self.HTTPComponent.Get( sUrl );

        if self.HTTPComponent.ResponseCode = 200 then begin
          break;
        end;

        // IDEIA - log what happend if not 200
        logWhatHappend( s, HTTPComponent ); // then log content, headers, etc
        inc( iRedo ); sleep( 5 );
      end;
Marcelo Martinez - neosys.info
  • 41
  • 1
  • 3