pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Brind <bri...@brindy.org.uk>
Subject Re: DigestAuthentication starts to work
Date Mon, 25 May 2009 16:48:44 GMT
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.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message