You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Jonathan Moore (JIRA)" <ji...@apache.org> on 2010/04/07 16:37:33 UTC

[jira] Commented: (HTTPCLIENT-427) Implement a cache to perform real request only when needed

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854521#action_12854521 ] 

Jonathan Moore commented on HTTPCLIENT-427:
-------------------------------------------

We're taking the approach of trying to be a conditionally-compliant (meaning, we implement all the MUSTs and MUST NOTs in the RFC) HTTP/1.1 transparent proxy cache, even though technically the CachingHttpClient decorator isn't a full proxy (since it doesn't actually talk HTTP with its upstream client; we use the HttpClient API). In general, we feel like this will maximize interoperability but could lead to some surprising behavior.

One example requirement of the RFC is: "Clients MAY issue simple (non-subrange) GET requests with either weak validators or strong validators. Clients MUST NOT use weak validators in other forms of request."

Let's say the client program issues a request like this:

PUT / HTTP/1.1
Host: foo.example.com
Content-Length: 6
Content-Type: text/plain
If-Match: W/"etag"

stuff

If I were a compliant, standalone proxy, I would not be allowed to send this request downstream per the RFC, and would probably return a 400 (Bad Request). Now, the CachingHttpClient could likewise construct a 400 response and hand it right back, but this might be surprising to a client who had previously been interacting with a non-compliant origin that allowed this, in which case the CachingHttpClient wouldn't really be a drop-in replacement.

Is there some community opinion on how to behave in cases like this? Is subjecting ourselves to the rigors of requirements on proxies too much? Should this type of behavior be configurable?


> Implement a cache to perform real request only when needed
> ----------------------------------------------------------
>
>                 Key: HTTPCLIENT-427
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-427
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient
>         Environment: Operating System: Linux
> Platform: PC
>            Reporter: Marc Guillemot
>            Priority: Minor
>             Fix For: Future
>
>
> Browsers may cache received content according to the values of different
> response headers. It would be great if HttpClient could do the same.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org