[cpp-netlib-devel] soliciting ideas concerning client errors

[John P. F. <jf...@ov...>]

At the moment this a basic_client::get() request from my branch, which 
is working off the trunk interface:

response const get( basic_request<tag> const & request_, const 
connection_type connection=persistent
) {
  return request_policy::sync_process
  (request_, "GET", true, follow_redirect_, connection, 
*connection_supplier_);
};

Concerning that, I'm not satisfied with the way errors are handled (or 
lack there-of). Some errors can be coped with and still complete the 
request; others can't. The question is how to handle the former.

My solution is to differ that choice to the user on a per request basis. 
This would be used to express certain server deviations from a protocol 
standard:

IE:
//rfc1945_extended is a request_policy based off the http 1.0 spec
struct rfc1945_extended::response_deviation {
   //IE: the request would still continue even if the server didn't
         acknowledge persistence or non-persistence, or provided a 
Connection:
         not in accordance with the specification
   bool allow_incorrect_persistence;
   bool allow_version_mismatch;
   bool allow_missing_whatever_header;
   ...
};
...
response const get(const response_deviation&, const 
std::stack<boost::error_code>& ...)

This makes a throw depend on a deviation. In any case, errors up to that 
point are still pushed to the stack which, with a response fragment, 
would accompany the exception.

Dean has also personally suggested an interface similar to this to 
toggle on/off throw, which I have modified for purposes of this
discussion:

  std::stack<boost::system::error_code> errors;
  http::response response; 
  http::rfc1945_extended::response_deviation deviation(..);
  tie(response, errors) = client.get(request, deviation, http::nothrow);

Questions and comments welcome.

John