A few things...
I think it will be better if I extend CefRequest with the flags and firstPartyForCookies properties so that I can keep that data together. Those two parameters would only matter for CefWebUrlRequest.
1. I don't really like the idea of adding parameters to CefRequest that are only used by CefWebUrlRequest. Instead, let's make |flags| and |firstPartyForCookies| parameters to Open and provide getters for them on CefWebUrlRequest if necessary.
// Sets the request parameters
/*--cef()--*/
virtual void Open(CefRefPtr<CefRequest> request) = 0;
// Starts the request asynchronously
/*--cef()--*/
virtual void Send(CefRefPtr<CefWebUrlRequestHandler> callback) = 0;
2a. Do Open and Send need to be separate methods? If someone will always call Open and then immediately call Send then it probably makes sense to have a single method that does both.
2b. Can a CefWebUrlRequestHandler object be re-used? If not, then we could potentially eliminate both Open and Send and instead pass |request|, |flags|, |firstPartyForCookies| and |callback| parameters to the static CreateWebUrlRequest method.
/ Gets the value for the specified response header field
/*--cef()--*/
virtual CefString GetHeader(const CefString& name) = 0;
// Gets all response headers.
/*--cef()--*/
virtual CefString GetAllHeaders() = 0;
3. CefResponse should provide a GetHeaderMap method to maintain consistency with CefRequest if possible.
// Notifies the handler that the request ended with an error.
// domain is a namespace for "reason".
/*--cef()--*/
virtual void OnError(CefRefPtr<CefWebUrlRequest> request, const CefString& domain, int reason) = 0;
4. What type of values will the |domain| parameter have?
(Should this be called CefWebUrlRequestor?)
5. Maybe CefWebUrlRequestClient or CefWebUrlRequestListener? Name the parameter |client| or |listener| respectively.