pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: DigestAuthentication starts to work
Date Mon, 25 May 2009 18:59:45 GMT
Yeah, that's pretty much what I was thinking. Thanks.
 
On Monday, May 25, 2009, at 12:48PM, "Christopher Brind" <brindy@brindy.org.uk> wrote:
>I agree that it's a bit excessive.
>
>There are two scenarios that spring to mind:
>1) A server error (either originating within the application as an unhandled
>runtime error, or before the application even gets called, e.g. a server
>configuration error, or something else none application specific).  In this
>case you you can never be sure what the server will actually return in the
>body for an error - at best some (hopefully well formatted) html, at worst,
>who knows!
>
>2) An application generated error in which case you can set the fault as a
>header in your server code and retrieve it in your client.  Though I would
>say that it probably isn't best practice to be sending human readable fault
>information to the client.
>
>In both cases the client should just interpret the response code and display
>something appropriate to the user (ideally localized), e.g. "There was an
>error connecting to the server, please try again later." or something.
>
>Cheers,
>Chris
>
>
>2009/5/25 Greg Brown <gkbrown@mac.com>
>
>> >> I still don't think we should need to modify the Query class to support
>> digest authentication. I'd suggest that this code go in the
>> DigestAuthentication class itself.
>> >I am sorry that you think so, but this minimal change (only move the
>> >if check on the status code some lines under) is necessary to have the
>> >responseHeaders filled with response data, so i can retry the query
>> >(they are get from connection).
>>
>> You are correct - the exception should be thrown after the headers have
>> been set. It is valid for a non-success response to return headers. I have
>> made this change.
>>
>> I wondered briefly if we should also support a response body in this case,
>> but I'm currently thinking no. We wouldn't be able to return the body as the
>> task result, since we throw in this case. We could potentially add a
>> "detail" property to QueryException, but then we'd need a way to specify a
>> serializer to use for the fault data (since it is potentially different from
>> the one for the success data). But this all seems excessive - if the server
>> needed to return additional information about the fault, it could do so via
>> a response header. I think that is sufficient. What do others think?
>>
>> Greg
>>
>>
>>
>

Mime
View raw message