403 status code discards content - is this a bug? is save to not discard it?

Giganews Newsgroups
Subject: 403 status code discards content - is this a bug? is save to not discard it?
Posted by:  jachguate (jachgua…@gmail.com)
Date: Thu, 4 Dec 2008


I'm using INDY 10.1.1 (close to the snapshot) to execute REST WebServices via standard HTTP put/get/delete commands.

On some situations, the server returns a ResponseCode other than 200 (for example, 403 for forbidden access), and also returns information about the situation originating the error as content (an XML document).

This is my first time with REST and maybe I'm wrong, but I think this is common behavior in this type of services.

The situation:

TIdHTTPProtocol intentionally ignore the content in this situation (403 Response code), in the CheckException procedure of the ProcessResponse method, even when the Code is in the ALIgnoreReplies array.  For debug proposes I commented out the lines switching the ContentStream of the response, but I'm wondering if is safe to let this lines stay commented for production.  I think, on any possible client I can imagine, there's no reason to discard the content part of the response at this level.

In most of the cases it is discarded with the exception raised, aborting the execution path.  In fact it requires extra-code to handle the exception and use the value.  With this in mind, I think the majority of current INDY applications will have no effect at all.

Just to form my criteria, I used Mozilla Firefox to make a get request to the server ensuring a 403 response code, and the browser displays the xml document as a result.  It makes me think the Indy behavior is wrong.

I'm trying to post this as a bug report, but I need someone with access to the bug reporting to make it on behalf of me.

The method I'm using now is this:

  procedure CheckException(AResponseCode: Integer; ALIgnoreReplies: array of Smallint;
    AUnexpectedContentTimeout: Integer = IdTimeoutDefault);
    i: Integer;
    LTempResponse: TStringStream;
    LTempStream: TStream;
    //LTempResponse := TStringStream.Create('');
    //LTempStream := Response.ContentStream;
    //Response.ContentStream := LTempResponse;
      FHTTP.ReadResult(Response, AUnexpectedContentTimeout);
      if High(ALIgnoreReplies) > -1 then begin
        for i := Low(ALIgnoreReplies) to High(ALIgnoreReplies) do begin
          if AResponseCode = ALIgnoreReplies[i] then begin
      raise EIdHTTPProtocolException.CreateError(AResponseCode, FHTTP.ResponseText, LTempResponse.DataString);
      //Response.ContentStream := LTempStream;

btw.... I have to create a new class to implement the delete method... which is missing in TIdCustomHTTP.  If I get access to report bugs... or to make the correction myself and commit the change via SVN... it will be awesome.