|Subject:||Re: 403 status code discards content - is this a bug? is save to not discard it?|
|Posted by:||Juan Antonio Castillo (jachguate) (jachgua…@gmail.com)|
|Date:||Thu, 04 Dec 2008|
Maybe it's not clear from my first post.
I'm asking for:
- someone who can put this issue in the bug list of INDY Team, or
someone inside the team to think the report is good enough to give me
access to put it directly to the list. Maybe someone from the team to
tell me this is not a good candidate to a bug request.
- Comments regarding to how the change I'm doing can affect existing
clients. I own some projects using TIdHTTP and, beyond I think this
will no affect, I want to know what some other people think.
> 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.
403 status code discards content - is this a bug? is save to not discard it? posted by jachguate on Thu, 4 Dec 2008