You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2005/01/07 17:35:16 UTC
HttpClient API redesign: high level component architecture (draft 1)
Folks,
I have been quietly working on the HttpClient 4.0 API redesign for quite
a while already. I am confident the time is right to start discussing
the high level concept of the new API and try to agree on the most
fundamental goals and priorities of the API (re-)design and most
fundamental principles of the new architecture.
I would like to open discussion by presenting a VERY rough sketch of how
I tend to see the future of we know today as Jakarta HttpClient (please
do not confuse with Commons HttpClient)
Please note this is far from being even close to something logically
coherent and consistent. I just felt that I should get your feedback as
early as possible.
Evil Comrade Oleg
======================================================================
GOALS
=====
* Transform HttpClient from a client-side monolithic library into a toolset
of loosely coupled components.
* Provide a more modular structure enabling the users to assemble custom
client- and server-side HTTP services
* Resolve the deficiencies of the 3.0 API
COMPONENT STRUCTURE
===================
This is a purely logical distinction. The below listed components may be
distributed separately or as a part of a larger package (jar).
http-common
-----------
depends on
- Java 1.4 (shall we consider 1.5?)
- commons-logging (*) (if feasible I'd rather do without this dependency)
* Http header primitives as defined in RFC 822
- HttpHeader class
- HttpHeaderElement class
- HttpHeaderGroup class
* Http request line and Http status line primitives as defined in RFC 2616
- HttpVersion class
- HttpStatus class
- HttpRequestLine class
- HttpSatusLine class
* Http parameter primitives (see preference architecture in 3.0 API)
- HttpParams interface
- DefaultHttpParams class
* Http request and Http response interfaces as defined in RFC 2616 and their
generic implementation
- HttpRequest interface
- HttpResponse interface
- HttpEntityEnclosingRequest interface
- HttpRequestParams class
- BasicHttpRequest class implementing HttpRequest
- BasicHttpResponse class implementing HttpResponse
- BasicHttpEntityEnclosingRequest class implementing HttpEntityEnclosingRequest
* Http parser interface and the RFC 2616 compliant implementation of it. The
parser must only be able to parse well formed Http requests and responses.
- HttpParser interface
- NIOHttpParser class based on NIO (makes use of Socketchannel and CharBuffer)
* Http connection interface including a simple dependency mechanism to inject
an Http parser implementation, and a generic implementation of Http connection
- HttpConnection interface
- HttpConnectionParams class
- NIOHttpConnection class based on NIO (makes use of Socketchannel)
* Input / output chunking streams
- ChunkedInputStream class
- ChunkedOutputStream class
* HttpFilter interface allowing for request pre-processing and response post-
processing without having to subclass a given HttpRequest or HttpResponse
implementing classes
- HttpFilter interface
* HttpMethodExecutor class capable of executing http requests and receiving
Http responses. This class also is capable of retrying failed requests
and provides a means of injecting a number of Http filters. This class DOES
NOT provide connection pooling/management facilities, and DOES NOT handle
redirects and authentication challenges.
- HttpMethodExecutor class
- HttpRequestRetryHandler interface
- DefaultHttpRequestRetryHandler class implementing HttpRequestRetryHandler
interface
http-cookie
-----------
depends on
- Java 1.2
- commons-logging (*) (if feasible I'd rather do without this dependency)
- http-common (*) (if feasible I'd rather do without this dependency)
* Http cookie interface as defined in RFC2965 and RFC2109 and compatible with
Netscape cookie draft and servlet specification. Generic Http cookie
implementation.
- HttpCookie interface
- Cookie class (client side cookie)
- SetCookie class (Server side cookie)
* Http cookie specification interface that defines the contract for cookie
parsing, validation, formatting and matching.
- HttpCookieSpec interface
- CompatibilityCookieSpec class
- RFC2965CookieSpec class as defined in RFC 2965
- RFC2109CookieSpec class as defined in RFC 2109
- NetscapeCookieSpec class as defined in the Netscape cookie draft
http-auth
-----------
depends on
- Java 1.4
- commons-logging (*) (if feasible I'd rather do without this dependency)
- commons-codec
- http-common
* Http credentials primitives
- Credentials interface
- BasicCredentials class implementing Credentials interface
- WindowsCredentials class implementing Credentials interface
* Http authentication primitives. Authentication schemes should be
able to be produce and respond to authentication challenges (both
client and server side)
- AuthScheme interface
- BasicScheme class implementing HttpState
- DigestScheme class implementing HttpState
- NTLMScheme class implementing HttpState
- AuthChallengeParser class
http-client
-----------
depends on
- Java 1.4
- commons-logging (logging UGLI? vote?)
- commons-codec
- commons-pool (needed? vote?)
- http-common
- http-cookie
- http-auth
* Http connection manager / connection pool interface and most common
implementations of it.
- HttpConnectionManagerParams class
- HttpConnectionManager interface
- SimpleConnectionManager class implementing HttpConnectionManager
interface
- PoolingConnectionManager class implementing HttpConnectionManager
interface
* Http state primitives. Http state stores Http session data: credentials,
cookies.
- HttpState interface
- CredentialsProvider interface
- InMemoryHttpState class implementing HttpState interface
* Http agent primitives
- HttpClientParams class
- AuthChallengeHandler interface
- StdAuthChallengeHandler class implementing AuthChallengeHandler interface
- RedirectHandler interface
- StdRedirectHandler class implementing RedirectHandler interface
- StdAuthChallengeHandler class implementing AuthChallengeHandler interface
- HttpHost class
- HttpProxyHost class
- HttpHostParams class
- HostConfig class
- HttpClient class. Supports a simple dependency injection mechanism to
inject HttpConnectionManager, AuthChallengeHandler, RedirectHandler, HttpFilter
and possibly other dependencies.
http-client-3-compat
--------------------
depends on
- Java 1.4
- commons-logging
- commons-codec
- http-common
- http-cookie
- http-auth
- http-client
If there are any volunteers to maintain it. <warning>Count me out.</warning>
http-spider
--------------------
depends on
- Java 1.4
- commons-logging
- commons-codec
- http-common
- http-cookie
- http-auth
- http-client
A web crawler of a sort. Need more people on board
ideas?
http-proxy
--------------------
depends on
- Java 1.4
- commons-logging
- commons-codec
- http-common
- http-cookie
- http-auth
- geronimo-network (appropriate? better options? vote?)
A simple reverse proxy of a sort. Need MORE people on board
ideas?
http-server
--------------------
depends on
- Java 1.4
- commons-logging
- commons-codec
- http-common
- http-cookie
- http-auth
- geronimo-network (appropriate? better options? vote?)
A simple embeddable HTTP server of a sort. Need MOOOOOOOORE people on board.
ideas?
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HttpClient API redesign: high level component architecture
(draft 1)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2005-01-07 at 15:40 -0600, Chris Lamprecht wrote:
> This is interesting. I was thinking that after google desktop search,
> others may follow with a similar "mini-http server" running right on
> the client machine to provide the familiar browser interface (whether
> it be for search or something else). I think a full J2EE
> spec-compliant servlet container may be overkill (and have too many or
> too large dependencies), but it would be cool to have a subset of this
> functionality.
>
> What did you have in mind for this component?
>
Chris, David, et al
I (dare I say we?) do not have any concrete ideas in mind at this point.
We would like to leverage our expertise based on several years of
experience with client side HTTP to extend the scope of the project into
the server realm. The whole point is that this should open up a lot of
opportunities for other people to join and start contributing (ideas or
code) and build upon the existing code base. Beyond that, anything goes:
embedded lightweight HTTP server, caching API, what not. If HttpClient
project end up being to constraining, there is always possibility to
spin off or join another project provided there's a healthy community of
contributors and users.
So, we do welcome new ideas/critique, new users, and potentially new
contributors.
Oleg
> -chris
>
> > http-server
> > --------------------
> > depends on
> > - Java 1.4
> > - commons-logging
> > - commons-codec
> > - http-common
> > - http-cookie
> > - http-auth
> > - geronimo-network (appropriate? better options? vote?)
> >
> > A simple embeddable HTTP server of a sort. Need MOOOOOOOORE people on board.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HttpClient API redesign: high level component architecture (draft 1)
Posted by Chris Lamprecht <cl...@gmail.com>.
This is interesting. I was thinking that after google desktop search,
others may follow with a similar "mini-http server" running right on
the client machine to provide the familiar browser interface (whether
it be for search or something else). I think a full J2EE
spec-compliant servlet container may be overkill (and have too many or
too large dependencies), but it would be cool to have a subset of this
functionality.
What did you have in mind for this component?
-chris
> http-server
> --------------------
> depends on
> - Java 1.4
> - commons-logging
> - commons-codec
> - http-common
> - http-cookie
> - http-auth
> - geronimo-network (appropriate? better options? vote?)
>
> A simple embeddable HTTP server of a sort. Need MOOOOOOOORE people on board.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HttpClient API redesign: high level component architecture
(draft 1)
Posted by Oleg Kalnichevski <ol...@apache.org>.
Hi Mike,
Thanks for the feedback.
On Sat, 2005-01-08 at 13:47 -0500, Michael Becke wrote:
> I think we would want both individual component jars as well a
> monolithic jars for things like http-client.
>
Agreed.
> My preference would be for 1.4 unless there is a major feature in 1.5
> we cannot live without. I can't think of one at the moment.
>
I think we should hold a poll among HttpClient users and make a decision
based on the results of the poll. I also tend to favor Java 1.4.
> If no commons-logging, what would we use instead? UGLI? Something
> custom?
I have been thinking about not doing logging in the http-common at all.
Trivial method entry/exit traces can/should be added by using an aspect
of an AOP library. The context logging / wire logging _possibly_ could
be exclusively done at http-client / http-proxy / http-server level. I
am not absolutely positive it is technically feasible, though.
Not having http-common tied to a specific logging toolkit may prove
beneficial if it ever comes to trying to "sell" it to other projects,
such Tomcat
> Are you envisioning something similar to servlet filters? Would we use
> this internally to handle cookies, authentication, etc.?
>
Pretty much. The cookie handling, authentication, redirect handling
implemented as a bunch filters is an idea worth exploring.
> logging seems to be an issue in general. Whatever we choose, I think
> we need to be consistent and use the same logging at all levels.
>
Agreed. Still, I would rather have logging aspects inserted at a higher
level, for the same reason mentioned above.
> This has been discusses in other threads, but do we want to keep NTLM
> or should we make it dependent on an external package like JCIFS? My
> preference would be to externalize this feature.
Same here. The trouble is we may have to keep some sort of NTLM support
internally, should the ASF decide to prohibit the direct use of LGPL
software
> > depends on
> > - commons-pool (needed? vote?)
>
> We could, but I'm not sure it's necessary.
>
I do not have a strong opinion here. We can still provide it as an
option out of the contrib package.
> > http-proxy
> > --------------------
> > depends on
> > - Java 1.4
> > - geronimo-network (appropriate? better options? vote?)
>
> Don't know anything about geronimo-network. What would this add?
>
The network protocol stack:
http://svn.apache.org/viewcvs.cgi/geronimo/trunk/sandbox/network/src/java/org/apache/geronimo/network/protocol/
Of course, writing a protocol stack can be a great fun, but I doubt we
can outdo the Geronimo folks. Unless geronimo-network comes with all
sorts of unnecessary dependencies we should try to reuse it
> Should we still be called HttpClient? If we have a simple server, a
> client, a spider, etc., it seems we're more that just a client.
>
Sure. At the same time I think http-common, http-cookie, http-auth and
http-client will completely absorb our existing resources and will keep
us busy for months if not years. As soon as there's enough work done on
server-side components we can consider rebranding. Until then let us not
create too much confusion unnecessarily.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HttpClient API redesign: high level component architecture (draft 1)
Posted by Michael Becke <be...@u.washington.edu>.
Hi Oleg,
First off, this is awesome. I think this lays out a great framework
for HttpClient's future. In-lined below are questions and comments.
> COMPONENT STRUCTURE
> ===================
>
> This is a purely logical distinction. The below listed components may
> be
> distributed separately or as a part of a larger package (jar).
I think we would want both individual component jars as well a
monolithic jars for things like http-client.
> http-common
> -----------
>
> depends on
> - Java 1.4 (shall we consider 1.5?)
My preference would be for 1.4 unless there is a major feature in 1.5
we cannot live without. I can't think of one at the moment.
> - commons-logging (*) (if feasible I'd rather do without this
> dependency)
If no commons-logging, what would we use instead? UGLI? Something
custom?
> * HttpFilter interface allowing for request pre-processing and
> response post-
> processing without having to subclass a given HttpRequest or
> HttpResponse
> implementing classes
>
> - HttpFilter interface
Are you envisioning something similar to servlet filters? Would we use
this internally to handle cookies, authentication, etc.?
> http-cookie
> -----------
>
> depends on
> - Java 1.2
> - commons-logging (*) (if feasible I'd rather do without this
> dependency)
logging seems to be an issue in general. Whatever we choose, I think
we need to be consistent and use the same logging at all levels.
> http-auth
> -----------
>
> - NTLMScheme class implementing HttpState
This has been discusses in other threads, but do we want to keep NTLM
or should we make it dependent on an external package like JCIFS? My
preference would be to externalize this feature.
> http-client
> -----------
>
> depends on
> - commons-pool (needed? vote?)
We could, but I'm not sure it's necessary.
> http-spider
>
> ideas?
Perhaps integration with Lucene for building a search index? Other
integration for handling spider results?
> http-proxy
> --------------------
> depends on
> - Java 1.4
> - geronimo-network (appropriate? better options? vote?)
Don't know anything about geronimo-network. What would this add?
Should we still be called HttpClient? If we have a simple server, a
client, a spider, etc., it seems we're more that just a client.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HttpClient API redesign: high level component architecture (draft 1)
Posted by Oleg Kalnichevski <ol...@apache.org>.
Done
http://wiki.apache.org/jakarta-httpclient/HttpClientApiRedesign
Cheers,
Oleg
On Mon, Jan 10, 2005 at 08:43:13AM +0100, Ortwin Gl?ck wrote:
> Oleg,
>
> Thanks for your work first of all. Could you be so kind and put this
> draft into the wiki? This makes it easy for a team to work on it until
> it reaches its final form.
>
> Cheers
>
> Odi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HttpClient API redesign: high level component architecture (draft
1)
Posted by Ortwin Glück <or...@nose.ch>.
Oleg,
Thanks for your work first of all. Could you be so kind and put this
draft into the wiki? This makes it easy for a team to work on it until
it reaches its final form.
Cheers
Odi
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HttpClient API redesign: high level component architecture (draft 1)
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
> I personally see little practical benefit in exposing 1xx responses
> outside the method executor, as they do not represent an atomic
> operation IMO. So I would advocate hiding 1xx but open to discussion.
See my other mail.
> I tend to think of http-spider having a very simple event driven design
> akin to that of SAX. All we probably want to do here is fire a bunch of
> events and let the higher level components deal with the details.
So the result of a "spider request" would be an event with the document,
and it is up to the application level event handler to generate followup
spider requests. That does make a lot of sense.
> > --- http-(reverse)-proxy & http-server ---
> > Being a project under the big roof of the Apache
> > family, do we really want to start working on an
> > "HTTP Server"?
>
> Of course not. The thing is we do need a simple HTTP server to be able
> the client side stuff. We can still keep it buried deep inside our test
> cases, but I would rather try to develop it generic enough to be useful
> beyond our testing framework.
>
> What is we keep the potentially contentious "server" term out of it
> and provisionally call it http-infra?
That's fine. http-test-server would be fine as well. Just so that
it is clear we do not intend to provide the Java reference for a
server side HTTP protocol stack.
> > [...] Tomcat comes into my mind, and
> > there might be other projects as well.
> > [...]
>
> A certain conflict of interests and overlap in development efforts is
> inevitable. However our focus would be completely different. What I was
> thinking of is a simple embeddable server component. I by no means
> advocate a development of a full-blown servlet container.
I wouldn't have expected you to do that ;-) When mentioning
Tomcat, I was only thinking of their HTTP connector, Coyote.
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/
I would expect a rather big, if not total, overlap here.
A Tomcat connector would probably be a good use case for
an embeddable server component.
cheers,
Roland
Re: HttpClient API redesign: high level component architecture
(draft 1)
Posted by Oleg Kalnichevski <ol...@apache.org>.
Hi Roland
See my comments in-lined
On Mon, 2005-01-10 at 16:26 +0100, Roland Weber wrote:
> Hi Oleg,
>
> I just got back to work today. What a nice surprise to
> see the first version of the 4.0 high level design :-)
> Here are my thoughts:
>
> --- http-common ---
> "The parser must only be able to..."
> Do you mean "does only have to be able to",
> or "is not allowed to handle anything else"?
> I guess it's the former, but I want to be sure.
>
I meant the former indeed. I'll update that section shortly
> Will the HttpMethodExecutor handle 100-continue
> responses or not?
Excellent question. I have not thought about it in great details yet.
> I'd say no, since they don't
> indicate errors requiring a retry.
> The interface of the HMExecutor will get more
> complicated if a response can be available before
> the request has been fully transmitted, but hiding
> 10x responses will cause problems elsewhere.
> So I would prefer an executor with an interface
> that at least allows for asynchronous execution,
> including intermediate responses.
I personally see little practical benefit in exposing 1xx responses
outside the method executor, as they do not represent an atomic
operation IMO. So I would advocate hiding 1xx but open to discussion.
> --- http-cookie ---
> Should we have an interface CookieStore here?
> It would be extended by HttpState in http-client.
>
Good idea
> --- http-auth ---
> Should the interface CredentialProvider be
> defined here rather than in http-client?
> Similar to http-cookie/CookieStore.
>
Good idea
> --- http-spider ---
> Spidering requires content handling, which can
> get ugly really fast. I guess by defining a very
> simple interface to obtain the links from a
> document and by having intentionally simple
> implementations, we could keep that in check.
> But we'll need an inner circle of evil comrades
> to deny requests for more intelligent content
> handling ;-)
;-)
I tend to think of http-spider having a very simple event driven design
akin to that of SAX. All we probably want to do here is fire a bunch of
events and let the higher level components deal with the details.
>
> --- http-(reverse)-proxy & http-server ---
> Being a project under the big roof of the Apache
> family, do we really want to start working on an
> "HTTP Server"?
Of course not. The thing is we do need a simple HTTP server to be able
the client side stuff. We can still keep it buried deep inside our test
cases, but I would rather try to develop it generic enough to be useful
beyond our testing framework.
What is we keep the potentially contentious "server" term out of it and provisionally call it http-infra?
> In general, the idea makes sense. We do have
> a lot of experience with HTTP. But there are
> others that are already working on the server
> side in Java. Tomcat comes into my mind, and
> there might be other projects as well.
>
> Rather than just taking what we got and extending
> it to the server side, we should search for projects
> that would make use of this component, then ask
> proactively what they would need and if they have
> code to share with us. That way, we might even
> find people willing to help with development.
> If we don't find projects willing to use our server
> side component (once there is one) beforehand,
> we shouldn't put any effort in it. This will prevent
> us from getting into somebody else's turf.
A certain conflict of interests and overlap in development efforts is
inevitable. However our focus would be completely different. What I was
thinking of is a simple embeddable server component. I by no means
advocate a development of a full-blown servlet container.
> Of course it never hurts to keep the option open
> and to factor out the stuff that might be useful
> on both sides.
>
Let's keep it as a long-term option. Anyhow, first things should come first.
cheers,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HttpClient API redesign: high level component architecture (draft 1)
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
I just got back to work today. What a nice surprise to
see the first version of the 4.0 high level design :-)
Here are my thoughts:
--- http-common ---
"The parser must only be able to..."
Do you mean "does only have to be able to",
or "is not allowed to handle anything else"?
I guess it's the former, but I want to be sure.
Will the HttpMethodExecutor handle 100-continue
responses or not? I'd say no, since they don't
indicate errors requiring a retry.
The interface of the HMExecutor will get more
complicated if a response can be available before
the request has been fully transmitted, but hiding
10x responses will cause problems elsewhere.
So I would prefer an executor with an interface
that at least allows for asynchronous execution,
including intermediate responses.
There is one more idea I'm having on this component,
but I'll send that in a separate mail.
--- http-cookie ---
Should we have an interface CookieStore here?
It would be extended by HttpState in http-client.
--- http-auth ---
Should the interface CredentialProvider be
defined here rather than in http-client?
Similar to http-cookie/CookieStore.
--- http-spider ---
Spidering requires content handling, which can
get ugly really fast. I guess by defining a very
simple interface to obtain the links from a
document and by having intentionally simple
implementations, we could keep that in check.
But we'll need an inner circle of evil comrades
to deny requests for more intelligent content
handling ;-)
--- http-(reverse)-proxy ---
Reverse proxying becomes really useful only
if the links within the documents, especially
HTML, are rewritten to point to the reverse
proxy. This is way messier than spidering, and
something we really don't want to get into.
Of course there's plenty of stuff to be done
apart from content handling, and we could try
to implement that while leaving the content
handling as an exercise to the reader. But
then we should give a less promising name
to the component. http-delegate?
I have some experience with the topic, but
I would have to hold back from this project
to avoid polluting it with my employer's
intellectual property.
--- http-server ---
Being a project under the big roof of the Apache
family, do we really want to start working on an
"HTTP Server"?
In general, the idea makes sense. We do have
a lot of experience with HTTP. But there are
others that are already working on the server
side in Java. Tomcat comes into my mind, and
there might be other projects as well.
Rather than just taking what we got and extending
it to the server side, we should search for projects
that would make use of this component, then ask
proactively what they would need and if they have
code to share with us. That way, we might even
find people willing to help with development.
If we don't find projects willing to use our server
side component (once there is one) beforehand,
we shouldn't put any effort in it. This will prevent
us from getting into somebody else's turf.
Of course it never hurts to keep the option open
and to factor out the stuff that might be useful
on both sides.
cheers,
Roland
Re: HttpClient API redesign: HLCA --- http-common ---
Posted by Michael Becke <be...@u.washington.edu>.
> I would rather see the same effect achieved by using the observable
> pattern and the HttpFilter interface. The user may choose to keep track
> of Http response objects received by the filter
I agree. I think this would be better handled more generically by
"listening" to the HTTP execution process.
> I REALLY like the idea of non-blocking requests. That would be quite a
> paradigm shift, though. This idea is definitely worth exploring. Could
> you add a section of this subject to the proposal draft in Wiki?
This is definitely a good idea. This would also be quite useful for
pipelining requests.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HttpClient API redesign: HLCA --- http-common ---
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
> I cant think of a good practical reason for keeping track of 1xx
> responses.
>
<quote source="RFC 2616, Section 10.1, Page 56">
Proxies MUST forward 1xx responses, unless the connection between the
proxy and its client has been closed, or unless the proxy itself
requested the generation of the 1xx response.
</quote>
That is the reason why 1xx responses need to be exposed, at least
in some cases. And if they are exposed, they should be treated like
other responses.
> How is the trace object supposed to be retrieved? Can we still keep
> HttpMethodExecutor stateless?
>
I don't know yet. I had the idea of using separate trace objects only
yesterday, while typing in the mail. I guess I'd pass the trace object
along with the request to each object that would need it. Optional.
> I would rather see the same effect achieved by using the observable
> pattern and the HttpFilter interface. The user may choose to keep track
> of Http response objects received by the filter
>
Sounds like a good alternative.
> I REALLY like the idea of non-blocking requests. That would be quite a
> paradigm shift, though. This idea is definitely worth exploring. Could
> you add a section of this subject to the proposal draft in Wiki?
>
If it can wait until the weekend, I'll do it. I'm currently a little
busy at work.
cheers,
Roland
Re: HttpClient API redesign: HLCA --- http-common ---
Posted by Oleg Kalnichevski <ol...@apache.org>.
Roland,
> So my questions are:
>
> - Does anyone else see the need for tracking these
> relations between request and response objects?
> (If not, forget the rest ;-)
>
I cant think of a good practical reason for keeping track of 1xx
responses.
> - Should that information be collected in the objects
> themselves? Then there would be query methods
> in the interfaces.
Maybe. HttpResponse#getIntermediateResponses is possibility, but a
fairly ugly one
>
> - Should that information be collected in separate
> objects instead? Then we need at least another
> interface, probably with default implementation.
> (That's why I raise this question now, while we
> are discussing an initial list of classes/interfaces
> for each component.)
> I like the separate objects better. I don't have a
> convicing idea for a name though.
> HttpMessageTrace?
> HttpPingPong?
> HttpChitChat?
>
How is the trace object supposed to be retrieved? Can we still keep
HttpMethodExecutor stateless?
I would rather see the same effect achieved by using the observable
pattern and the HttpFilter interface. The user may choose to keep track
of Http response objects received by the filter
> This idea combines nicely with asynchronous method
> execution. I might ask a request whether it has been
> sent already, whether there is a response, whether
> there is an ultimate response. If the request is sent,
> I might block until the next or ultimate response is
> available, with or without timeout.
>
I REALLY like the idea of non-blocking requests. That would be quite a
paradigm shift, though. This idea is definitely worth exploring. Could
you add a section of this subject to the proposal draft in Wiki?
Cheers,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HttpClient API redesign: HLCA --- http-common ---
Posted by Roland Weber <RO...@de.ibm.com>.
Hello Oleg, everyone,
here is the idea I am having regarding the http-common
component. I am putting this in a separate mail because
I'm not sure whether it should be discussed as part of
the high level design. So feel free to ignore it.
When I think about requests and responses, the picture
that forms in my mind is a ladder (roughly). A request
will generate a response, which might trigger a followup
request (redirect, auth) which will give another response.
There might be more than one response to a single
request in the presence of 10x intermediate responses.
POST req.1 ---> rsp.1a (100)
| \ |
| \ V
| --> rsp.1b (303)
| |
V V
GET req.2 ---> rsp.2 (200)
So, when I have an HTTP request object, I would like
to be able to query for the immediate response object,
the followup request object, the ultimate response, and
so on. Similar with a response object, where I might
want to ask for the request, immediate or initial. And
for the preceeding or subsequent or final response.
Such navigational structures would be build by the
RedirectHandler and AuthChallengeHandler in http-client,
but might also be composed in a bigger scope by
applications.
So my questions are:
- Does anyone else see the need for tracking these
relations between request and response objects?
(If not, forget the rest ;-)
- Should that information be collected in the objects
themselves? Then there would be query methods
in the interfaces.
- Should that information be collected in separate
objects instead? Then we need at least another
interface, probably with default implementation.
(That's why I raise this question now, while we
are discussing an initial list of classes/interfaces
for each component.)
I like the separate objects better. I don't have a
convicing idea for a name though.
HttpMessageTrace?
HttpPingPong?
HttpChitChat?
This idea combines nicely with asynchronous method
execution. I might ask a request whether it has been
sent already, whether there is a response, whether
there is an ultimate response. If the request is sent,
I might block until the next or ultimate response is
available, with or without timeout.
What do you think?
cheers,
Roland