You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Roland Weber <RO...@de.ibm.com> on 2005/01/15 13:51:16 UTC
HLCA: http-tunnel
Hello folks,
since the http-common component is meant to be useful
by it's own for simple HTTP communication, we should
give a little thought to those that might want to work on
that simple level. As soon as they have to communicate
through a proxy, they get a dependency on the http-client
component, which depends on several other components.
The dependencies seem even more excessive for people
who only want to tunnel an application specific protocol
through an HTTP proxy.
What do you think about a new component for the
proxy/tunneling support currently listed in http-client?
* http-tunnel depends on http-common
- ProxyConnectMethod implementing HttpRequest
? HttpProxyHost (only if HttpHost is moved to
http-common, to avoid dependency on http-client)
cheers,
Roland
Re: HLCA: http-tunnel
Posted by Michael Becke <be...@u.washington.edu>.
> The trouble is that any sort meaningful tunneling component most likely
> would require at least rudimentary HTTP authentication support (http-
> auth) and ability to retry HTTP requests (HttpMethodExecutor). Without
> these features ProxyConnectMethod and HttpProxyHost would be of very
> marginal use only.
While this is true, the same thing could be said of the http-common
package in general. To be really useful one needs the cookie and auth
packages in addition to http-common.
Based strictly upon dependencies I would say that common is probably
the best location for HttpHost, HttpProxyHost, and ProxyConnectMethod.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: http entities
Posted by Michael Becke <be...@u.washington.edu>.
I agree that we should be able to share implementations of HttpEntity.
The difference would be how the client and server sides populate and
use these classes.
Mike
On Jan 20, 2005, at 8:06 AM, Ortwin Glück wrote:
> Roland,
>
> I agree on a dedicated class for HttpEntity. But I think in- and
> outgoing fits nicer into a decorator pattern. I am not sure how in-
> and outgoing would differ from each other. Ideas?:
>
> the common interface:
> IHttpEntity interface
>
> the entities:
> StringHttpEntity class implements IHttpEntity
> ByteArrayHttpEntity class implements IHttpEntity
> StreamHttpEntity class implements IHttpEntity
>
> two decorators:
> OutgoingEntity class implements and references IHttpEntity
> IncomingEntity class implements and references IHttpEntity
>
> The could then be used like:
>
> ice = new IncomingEntity(new StreamHttpEntity(in));
> ice.getContentLength()
> ice.reset()
>
> oge = new OutgoingEntity(new StreamHttpEntity(in))
> oge.isBuffered()
> oge.write(out)
>
>
> Roland Weber wrote:
>> Hello folks,
>> as I have briefly mentioned in a previous mail, I would like to
>> move the handling of HTTP entities into dedicated classes,
>> instead of having it in method implementations. The main
>> reasons for this are:
>> 1. entities have to be put into HTTP responses as well, though
>> these tend to be more simple than the multipart entities
>> frequently found in requests
>> 2. all entity enclosing methods (in particular POST and PUT)
>> should provide identical means for defining entities, without
>> having to duplicate code
>> 2. on the server side, a method will provide access to the
>> enclosed entity but does not allow to define it
>> In the light of Oleg's attempts to make request and response
>> objects useful on both client and server side, I believe that
>> separate entity handling classes will simplify re-use. And
>> here is my first take on it:
>> http-common:
>> HttpEntity interface
>> HttpOutgoingEntity extends HttpEntity (was: RequestEntity)
>> HttpIncomingEntity extends HttpEntity
>> BasicEntity implements HttpEntity
>> BasicOgEntity extends BasicEntity implements HttpOutgoingEntity
>> BasicIcEntity extends BasicEntity implements HttpIncomingEntity
>> StringOgEntity extends BasicOgEntity
>> ByteArrayOgEntity extends BasicOgEntity
>> InputStreamOgEntity extends BasicOgEntity
>> FormDataOgEntity extends BasicOgEntity
>> based on code currently in PostMethod
>> OutputStreamIcEntity extends BasicIcEntity
>> ByteArrayIcEntity extends BasicIcEntity
>> (Rename EntityEnclosingMethod to something that can
>> reasonably be implemented by HttpResponse as well?)
>> http-multipart:
>> MultipartOgEntity extends BasicOgEntity
>> based on current code in o.a.c.hc.methods.multipart
>> (Part, PartBase, StringPart, ByteArrayPart, FilePart
>> PartSource, ByteArrayPartSource, FilePartSource)
>> MultipartIcEntity extends BasicIcEntity
>> based on Commons FileUpload - as a future extension
>> What do you think? I will take care of updating the
>> design document once we have reached a consensus.
>> cheers,
>> Roland
>
> --
> _________________________________________________________________
> NOSE applied intelligence ag
>
> ortwin glück [www] http://www.nose.ch
> software engineer
> hardturmstrasse 171 [pgp id] 0x81CF3416
> 8005 zürich [office] +41-1-277 57 35
> switzerland [fax] +41-1-277 57 12
>
> ---------------------------------------------------------------------
> 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: HLCA: http entities
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Odi, all,
The idea was that the OgEntities provide type
specific setters and implement the encoding of
the data as an entity, while IcEntities implement
the parsing and provide type specific getters.
I'll take "Gamma et al" home to check on the
Decorator pattern over the weekend.
The multipart entities will be moved to http-client.
Implementations based on different foreign
packages could go into a "contrib" component.
But we'll need at least one to make sure that
the generic API is sound, if we decide to define
one.
This makes multipart an example where we
don't want to have encoding and parsing
implemented in the same class.
cheers,
Roland
Ortwin Glück <or...@nose.ch> wrote on 20.01.2005 14:06:38:
> Roland,
>
> I agree on a dedicated class for HttpEntity. But I think in- and
> outgoing fits nicer into a decorator pattern. I am not sure how in- and
> outgoing would differ from each other. Ideas?:
>
> the common interface:
> IHttpEntity interface
>
> the entities:
> StringHttpEntity class implements IHttpEntity
> ByteArrayHttpEntity class implements IHttpEntity
> StreamHttpEntity class implements IHttpEntity
>
> two decorators:
> OutgoingEntity class implements and references IHttpEntity
> IncomingEntity class implements and references IHttpEntity
>
> The could then be used like:
>
> ice = new IncomingEntity(new StreamHttpEntity(in));
> ice.getContentLength()
> ice.reset()
>
> oge = new OutgoingEntity(new StreamHttpEntity(in))
> oge.isBuffered()
> oge.write(out)
>
>
> Roland Weber wrote:
> > Hello folks,
> >
> > as I have briefly mentioned in a previous mail, I would like to
> > move the handling of HTTP entities into dedicated classes,
> > instead of having it in method implementations. The main
> > reasons for this are:
> >
> > 1. entities have to be put into HTTP responses as well, though
> > these tend to be more simple than the multipart entities
> > frequently found in requests
> > 2. all entity enclosing methods (in particular POST and PUT)
> > should provide identical means for defining entities, without
> > having to duplicate code
> > 2. on the server side, a method will provide access to the
> > enclosed entity but does not allow to define it
> >
> > In the light of Oleg's attempts to make request and response
> > objects useful on both client and server side, I believe that
> > separate entity handling classes will simplify re-use. And
> > here is my first take on it:
> >
> >
> > http-common:
> >
> > HttpEntity interface
> > HttpOutgoingEntity extends HttpEntity (was: RequestEntity)
> > HttpIncomingEntity extends HttpEntity
> >
> > BasicEntity implements HttpEntity
> > BasicOgEntity extends BasicEntity implements HttpOutgoingEntity
> > BasicIcEntity extends BasicEntity implements HttpIncomingEntity
> >
> > StringOgEntity extends BasicOgEntity
> > ByteArrayOgEntity extends BasicOgEntity
> > InputStreamOgEntity extends BasicOgEntity
> >
> > FormDataOgEntity extends BasicOgEntity
> > based on code currently in PostMethod
> >
> > OutputStreamIcEntity extends BasicIcEntity
> > ByteArrayIcEntity extends BasicIcEntity
> >
> > (Rename EntityEnclosingMethod to something that can
> > reasonably be implemented by HttpResponse as well?)
> >
> >
> > http-multipart:
> >
> > MultipartOgEntity extends BasicOgEntity
> > based on current code in o.a.c.hc.methods.multipart
> > (Part, PartBase, StringPart, ByteArrayPart, FilePart
> > PartSource, ByteArrayPartSource, FilePartSource)
> >
> > MultipartIcEntity extends BasicIcEntity
> > based on Commons FileUpload - as a future extension
> >
> >
> > What do you think? I will take care of updating the
> > design document once we have reached a consensus.
> >
> > cheers,
> > Roland
> >
> >
> >
> >
>
> --
> _________________________________________________________________
> NOSE applied intelligence ag
>
> ortwin glück [www] http://www.nose.ch
> software engineer
> hardturmstrasse 171 [pgp id] 0x81CF3416
> 8005 zürich [office] +41-1-277 57 35
> switzerland [fax] +41-1-277 57 12
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
Re: HLCA: http entities
Posted by Ortwin Glück <or...@nose.ch>.
Roland,
I agree on a dedicated class for HttpEntity. But I think in- and
outgoing fits nicer into a decorator pattern. I am not sure how in- and
outgoing would differ from each other. Ideas?:
the common interface:
IHttpEntity interface
the entities:
StringHttpEntity class implements IHttpEntity
ByteArrayHttpEntity class implements IHttpEntity
StreamHttpEntity class implements IHttpEntity
two decorators:
OutgoingEntity class implements and references IHttpEntity
IncomingEntity class implements and references IHttpEntity
The could then be used like:
ice = new IncomingEntity(new StreamHttpEntity(in));
ice.getContentLength()
ice.reset()
oge = new OutgoingEntity(new StreamHttpEntity(in))
oge.isBuffered()
oge.write(out)
Roland Weber wrote:
> Hello folks,
>
> as I have briefly mentioned in a previous mail, I would like to
> move the handling of HTTP entities into dedicated classes,
> instead of having it in method implementations. The main
> reasons for this are:
>
> 1. entities have to be put into HTTP responses as well, though
> these tend to be more simple than the multipart entities
> frequently found in requests
> 2. all entity enclosing methods (in particular POST and PUT)
> should provide identical means for defining entities, without
> having to duplicate code
> 2. on the server side, a method will provide access to the
> enclosed entity but does not allow to define it
>
> In the light of Oleg's attempts to make request and response
> objects useful on both client and server side, I believe that
> separate entity handling classes will simplify re-use. And
> here is my first take on it:
>
>
> http-common:
>
> HttpEntity interface
> HttpOutgoingEntity extends HttpEntity (was: RequestEntity)
> HttpIncomingEntity extends HttpEntity
>
> BasicEntity implements HttpEntity
> BasicOgEntity extends BasicEntity implements HttpOutgoingEntity
> BasicIcEntity extends BasicEntity implements HttpIncomingEntity
>
> StringOgEntity extends BasicOgEntity
> ByteArrayOgEntity extends BasicOgEntity
> InputStreamOgEntity extends BasicOgEntity
>
> FormDataOgEntity extends BasicOgEntity
> based on code currently in PostMethod
>
> OutputStreamIcEntity extends BasicIcEntity
> ByteArrayIcEntity extends BasicIcEntity
>
> (Rename EntityEnclosingMethod to something that can
> reasonably be implemented by HttpResponse as well?)
>
>
> http-multipart:
>
> MultipartOgEntity extends BasicOgEntity
> based on current code in o.a.c.hc.methods.multipart
> (Part, PartBase, StringPart, ByteArrayPart, FilePart
> PartSource, ByteArrayPartSource, FilePartSource)
>
> MultipartIcEntity extends BasicIcEntity
> based on Commons FileUpload - as a future extension
>
>
> What do you think? I will take care of updating the
> design document once we have reached a consensus.
>
> cheers,
> Roland
>
>
>
>
--
_________________________________________________________________
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer
hardturmstrasse 171 [pgp id] 0x81CF3416
8005 zürich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: http entities
Posted by Ortwin Glück <or...@nose.ch>.
Oleg Kalnichevski wrote:
> As to http-multipart, there are plans to factor the multipart related
> stuff out and merge it with commons-codec
May I note, that you can also use the Multipart-MIME functionality that
is built into JavaMail. At least for parsing that has proven possible.
For assembly this should be no problem either. But of course that would
mean introducing a dependcy on JavaMail (which is not a large package
and included in J2EE anyway).
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: http entities
Posted by Oleg Kalnichevski <ol...@apache.org>.
Roland,
Looks very good to me. Many thanks for your continued efforts.
I also tend to think that Odi has made a good point about the decorator
pattern, but the exact details of each and every class and interface
cannot be determined at this point, and they are not meant to be final
anyways.
As to http-multipart, there are plans to factor the multipart related
stuff out and merge it with commons-codec
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/codec-
multipart/
Unfortunately there as been no progress made on that front for months,
so the outcome of this endeavor is far from being certain. Still,
architecture-wise this seems a better option to me. All we would have to
do is to provide MultipartIcEntity and MultipartOgEntity out of http-
client package, which is already dependent commons-codec anyways
Cheers,
Oleg
On Thu, 2005-01-20 at 13:47 +0100, Roland Weber wrote:
> Hello folks,
>
> as I have briefly mentioned in a previous mail, I would like to
> move the handling of HTTP entities into dedicated classes,
> instead of having it in method implementations. The main
> reasons for this are:
>
> 1. entities have to be put into HTTP responses as well, though
> these tend to be more simple than the multipart entities
> frequently found in requests
> 2. all entity enclosing methods (in particular POST and PUT)
> should provide identical means for defining entities, without
> having to duplicate code
> 2. on the server side, a method will provide access to the
> enclosed entity but does not allow to define it
>
> In the light of Oleg's attempts to make request and response
> objects useful on both client and server side, I believe that
> separate entity handling classes will simplify re-use. And
> here is my first take on it:
>
>
> http-common:
>
> HttpEntity interface
> HttpOutgoingEntity extends HttpEntity (was: RequestEntity)
> HttpIncomingEntity extends HttpEntity
>
> BasicEntity implements HttpEntity
> BasicOgEntity extends BasicEntity implements HttpOutgoingEntity
> BasicIcEntity extends BasicEntity implements HttpIncomingEntity
>
> StringOgEntity extends BasicOgEntity
> ByteArrayOgEntity extends BasicOgEntity
> InputStreamOgEntity extends BasicOgEntity
>
> FormDataOgEntity extends BasicOgEntity
> based on code currently in PostMethod
>
> OutputStreamIcEntity extends BasicIcEntity
> ByteArrayIcEntity extends BasicIcEntity
>
> (Rename EntityEnclosingMethod to something that can
> reasonably be implemented by HttpResponse as well?)
>
>
> http-multipart:
>
> MultipartOgEntity extends BasicOgEntity
> based on current code in o.a.c.hc.methods.multipart
> (Part, PartBase, StringPart, ByteArrayPart, FilePart
> PartSource, ByteArrayPartSource, FilePartSource)
>
> MultipartIcEntity extends BasicIcEntity
> based on Commons FileUpload - as a future extension
>
>
> What do you think? I will take care of updating the
> design document once we have reached a consensus.
>
> cheers,
> Roland
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: http entities - take two
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Mike, Oleg,
> > First off, this leaves us some room for maneuvers. We will not have to
> > worry about invalidating the API redesign document, should we discover
> > a
> > better approach. Secondly, we do not have to commit ourselves to any
of
> > the JRE specifics.
> >
> > What do you think?
>
> I completely agree. We should leave the specifics to implementation
> time.
>
I also agree. I just added the methods to the mail so you know better what
I have in mind.
cheers,
Roland
Re: HLCA: http entities - take two
Posted by Michael Becke <be...@u.washington.edu>.
> First off, this leaves us some room for maneuvers. We will not have to
> worry about invalidating the API redesign document, should we discover
> a
> better approach. Secondly, we do not have to commit ourselves to any of
> the JRE specifics.
>
> What do you think?
I completely agree. We should leave the specifics to implementation
time.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: http entities - take two
Posted by Oleg Kalnichevski <ol...@apache.org>.
Hi Roland
I am +1 on committing these changes to the AP redesign document.
I have only one comment. Let us not get too obsessed with details at
this moment. The exact method signatures and design patterns may be
difficult to get right at this level of abstraction. Probably we should
even try.
The main goal of this work, imo, is to determine the most fundamental
interfaces and classes, relationship between these classes, and the most
efficient packaging of related classes and interfaces with least amount
of coupling and external dependencies. The rest the code will tell.
In this vein I suggest we leave method signatures out of this document
- HttpMessage as base interface for HttpRequest, HttpResponse
- - getHeader(), setHeader()
+ HttpMessage as base interface for HttpRequest, HttpResponse. This
+ interface defines methods to manipulate http headers.
First off, this leaves us some room for maneuvers. We will not have to
worry about invalidating the API redesign document, should we discover a
better approach. Secondly, we do not have to commit ourselves to any of
the JRE specifics.
What do you think?
Oleg
On Sat, 2005-01-22 at 08:32 +0100, Roland Weber wrote:
> Hello again,
>
> here is take two on moving http entities into their own
> class hierarchy. The Decorator pattern for input/output
> does not really fit, because writing or reading an entity
> is not a functionality that can be implemented without
> internal knowledge of the entity itself.
> What I intend is closer to the Strategy pattern. There
> is a strategy for writing an entity, and one for reading
> an entity. The various Ic and Og classes implement such
> strategies for a particular type of entity.
>
> To reduce the number of classes, I have moved both strategies
> into one for the simple in-memory entity types. I also dropped
> the BasicOgEntity and BasicIcEntity classes because I don't
> know what would actually be implemented there and because
> I can't derive from both of them at the same time.
>
> Here is what it looks like now, with suggestions for the
> methods that go into some of the classes and interfaces.
> I'm old-fashioned, so it's java.io rather than java.nio
> for the time being ;-)
>
>
> http-common
>
> HttpMessage as base interface for HttpRequest, HttpResponse
> - getHeader(), setHeader()
>
> HttpEntity interface
> - getContentLength(), getContentType()
> HttpOutgoingEntity interface extends HttpEntity
> - isRepeatable(), writeTo(OutputStream)
> HttpIncomingEntity interface extends HttpEntity
> - readFrom(HttpMessage, InputStream) ?
> (or have that functionality in a constructor)
>
> BasicEntity implements HttpEntity
> - public getContentLength(), getContentType()
> - protected setContentLength(), setContentType()
>
> StringEntity extends BasicEntity
> implements HttpOutgoingEntity, HttpIncomingEntity
> ByteArrayEntity extends BasicEntity
> implements HttpOutgoingEntity, HttpIncomingEntity
>
> InputStreamOgEntity extends BasicEntity
> implements HttpOutgoingEntity
> OutputStreamIcEntity extends BasicEntity
> implements HttpIncomingEntity
>
>
> http-client
>
> FormDataEntity extends BasicEntity
> implements HttpOutgoingEntity, HttpIncomingEntity
> uses commons-codec, therefore in http-client
>
> MultipartOgEntity extends BasicEntity
> implements HttpOutgoingEntity
> based on commons-codec or code in o.a.c.hc.methods.multipart
>
> MultipartIcEntity extends BasicEntity
> implements HttpIncomingEntity
> based on commons-codec (only if available)
> alternative implementations based on javax.mail or
> commons-fileupload can be kept in a "contrib" component
> once they are contributed
>
>
> What do you think?
>
> cheers,
> Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: SingleProxy extending SimpleProxyChain
Posted by Ortwin Glück <or...@nose.ch>.
Roland Weber wrote:
>> SimpleProxyChain class implementing ProxyChain.
>> List of HttpProxyHost objects.
>>
>> SingleProxy class extending SimpleProxyChain.
>> For use when a single proxy server is used.
>
>
> It seems odd to me to derive the single-object implementation
> from the list-of-objects implementation. At least I have
> always run into problems when I tried to restrict base class
> functionality in a derived class. That's just not what the
> (contravariant) inheritance mechanism is meant for.
>
> If we expect signifcant code re-use between the two different
> implementations, let's introduce an abstract base class. If
> not, let's just have a SingleProxy implementing ProxyChain
> without a base class.
>
> What do you think?
Agreed. Better have an interface than semantically odd inheritance.
--
_________________________________________________________________
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer
hardturmstrasse 171 [pgp id] 0x81CF3416
8005 zürich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: generating followup requests
Posted by Michael Becke <be...@u.washington.edu>.
> I was worried about the authentication state as well. I guess an
> authentication handler can detect from the request and response that
> a previous authentication state has become invalid and reset itself.
> The question whether the authentication state is stored in the handler
> itself or as part of the connection or session or whatever will have
> to be answered before we can give a final answer to the reset problem.
> I hope for some insightful comments from Mike here. If I remember
> correctly, he did some of the work on the authentication code.
I think it may depend on the type of authentication. Basic doesn't
really need any context. NTLM on the other hand requires all sorts of
context. Not only does it need request context for the sequence of
challenges, but if I remember correctly it's actually a connection
based authentication scheme.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: generating followup requests
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
> Here is my take. Overall I find FollowupHandler and FollowupHandlerChain
> to be a good idea worth exploring. (Can HttpSequenceHandler be
> potentially a better name, though?)
Yes, that would be a better name. I didn't want to get into the name
discussion until getting feedback on the idea itself :-) Maybe leave
the Handler out and make it an HttpSequencer?
> As to a better componentization, I am not entirely convinced
>
> The trouble is that I see no clear way to separate redirect handling and
> authentication handling, as the redirect handler may need to reset the
> state of the authentication process.
I was worried about the authentication state as well. I guess an
authentication handler can detect from the request and response that
a previous authentication state has become invalid and reset itself.
The question whether the authentication state is stored in the handler
itself or as part of the connection or session or whatever will have
to be answered before we can give a final answer to the reset problem.
I hope for some insightful comments from Mike here. If I remember
correctly, he did some of the work on the authentication code.
> At the moment I see no way around a
> limited redirect code duplication if we still want to keep all the
> authentication aspects out of http-common. We may think of an additional
> abstraction layer in a form of HttpContext, which would enable the
> redirect handler to reset the authentication process without being
> directly coupled with any of the authentication classes. However, I am
> unable to say at this point if this is feasible.
I get a strong déjà vu :-) In OpenCard, we had to store state information
about the smartcard, and changing the selection on the smartcard would
invalidate the authentication state. Unfortunately, we didn't come up
with an ultimate solution while I was involved in the project. The state
was associated with a channel, that's why I mentioned the connection
association above. I just don't think the analogy extends to basic auth.
Anyway, I would prefer to have all the logic in one or several handlers
rather than two interfaces for authentication and redirect handlers along
with outside logic to invoke them.
cheers,
Roland
Re: HLCA: generating followup requests
Posted by Michael Becke <be...@u.washington.edu>.
> I will. But I don't want to be seen as usurping the API redesign lead
> either. The revision history of the HLCA is not exactly a showcase for
> diversity ;-)
Not to worry, this is how things get done. Someone is interested and
takes the time to make things happen. If anyone has a problem with the
direction of the HLCA they only need to speak up. My preference is for
discussion on the mailing list and for someone (you and Oleg so far) to
take the initiative to put the ideas together into a document.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: generating followup requests
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
> > Will you update the design document or should I? After giving others
> > time to enter this discussion, of course.
>
> I do not want to be seen as usurping the API redesign leads. Do feel
> free to go ahead and update the HLCA document, if you like.
I will. But I don't want to be seen as usurping the API redesign lead
either. The revision history of the HLCA is not exactly a showcase for
diversity ;-)
I'll try to come up with a few paragraphs on use cases a.s.a.p.,
this weekend at latest. We have to get more people involved.
cheers,
Roland
Re: HLCA: generating followup requests
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, Feb 07, 2005 at 03:49:25PM +0100, Roland Weber wrote:
> Hi Oleg,
>
> > Correct me if I am wrong, essentially you are talking about the
> > 'request' scope (HttpMethodExecutor) and the 'session' scope
> > (HttpClient), not a hierarchy of contexts per se. Do I understand you
> > correctly?
>
> Yes. I see only those two levels that are needed.
>
> > I think HttpContext should always be of request visibility, however some
> > specific objects contained in the context may contain information that
> > spans across several request/response pairs, such as CookieStore,
> > AuthState/AuthScheme. Currently I see this as the simplest solution that
> > works, and I like keeping things simple.
>
> So in order to share data between different contexts/sequences, the
> context
> has to be (pre-)populated with objects that are present in those other
> contexts as well.
Exactly
>
> > What do you think?
> >
> I think that is a good solution for the problem at hand, and simpler than
> dealing with a hierarchy of contexts. Improves data encapsulation, too.
> Go ahead, I'm with you now :-)
>
> Btw, I just checked the digest auth scheme to come up with a concrete
> example, and it would have been hell using a hierarchy... ;-)
>
>
> Will you update the design document or should I? After giving others
> time to enter this discussion, of course.
>
I do not want to be seen as usurping the API redesign leads. Do feel
free to go ahead and update the HLCA document, if you like.
Cheers,
Oleg
> cheers,
> Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: collect uses cases?
Posted by Oleg Kalnichevski <ol...@apache.org>.
Roland,
This is an excellent idea! That would enable the users to provide some
input without having to deal with the intricacies of the exisitng API
and the suggested HLCA
One big fat +1 from me
Oleg
On Mon, Feb 07, 2005 at 04:20:07PM +0100, Roland Weber wrote:
> Hello all,
>
> I was wondering whether we should collect some use cases as part of
> our ongoing discussion on the 4.0 High Level Component Architecture.
> Of course we don't have the resources to write down a full set of use
> cases starting with "get a page from an HTTP server". I was thinking
> along the lines of "really cool things I would want to do with the
> HttpClient". We could put such use cases into separate pages in the
> wiki and link to them from the HLCA document where appropriate. This
> might also encourage a few more people on this list to participate
> in the discussions, by contributing use cases. I don't insist on
> the term "use cases" either, we could call them "really cool things"
> as well :-)
>
> What do you think?
>
> cheers,
> Roland
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: collect uses cases?
Posted by Ortwin Glück <or...@nose.ch>.
+1
call the thing use case, if it is one.
my 0.02 €
Odi
Roland Weber wrote:
> Hello all,
>
> I was wondering whether we should collect some use cases as part of
> our ongoing discussion on the 4.0 High Level Component Architecture.
> Of course we don't have the resources to write down a full set of use
> cases starting with "get a page from an HTTP server". I was thinking
> along the lines of "really cool things I would want to do with the
> HttpClient". We could put such use cases into separate pages in the
> wiki and link to them from the HLCA document where appropriate. This
> might also encourage a few more people on this list to participate
> in the discussions, by contributing use cases. I don't insist on
> the term "use cases" either, we could call them "really cool things"
> as well :-)
>
> What do you think?
>
> cheers,
> Roland
--
_________________________________________________________________
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer
hardturmstrasse 171 [pgp id] 0x81CF3416
8005 zürich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: collect uses cases?
Posted by Michael Becke <be...@u.washington.edu>.
+1, an excellent idea.
Mike
Roland Weber wrote:
> Hello all,
>
> I was wondering whether we should collect some use cases as part of
> our ongoing discussion on the 4.0 High Level Component Architecture.
> Of course we don't have the resources to write down a full set of use
> cases starting with "get a page from an HTTP server". I was thinking
> along the lines of "really cool things I would want to do with the
> HttpClient". We could put such use cases into separate pages in the
> wiki and link to them from the HLCA document where appropriate. This
> might also encourage a few more people on this list to participate
> in the discussions, by contributing use cases. I don't insist on
> the term "use cases" either, we could call them "really cool things"
> as well :-)
>
> What do you think?
>
> cheers,
> Roland
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Wiki: Use Cases
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
I do have a tendency for overdesigning :-) I'm probably looking
too much at where I want to get instead of where I start.
I fully agree that the template in it's current form will
discourage some people, just because of the size of it. On
the other hand, I like the idea of a fully structured collection
of use cases with all the stuff in the template.
It's somehow similar with the categories. Once we have over
200 use cases, we sure want some kind of structure in there.
I thought of the "Engineered Use Cases" as a place where I can
put some of the things I thought about when discussing the
HLCA :-)
And finally, I read that Wiki pages can not easily be deleted,
which makes me hesitant about redundant and nonsensical contributions.
So I see two possibilities:
1) forget about the fully structured collection
2) have a sandbox for easy submission of use cases, and a separate
fully structured collection maintained by volunteers that process
input from the sandbox and the mailing lists
Obviously, I would prefer the second choice. And I volunteer to
add some more fully structured use cases over time.
What do you (all) think?
cheers,
Roland
Oleg Kalnichevski <ol...@apache.org>
15.02.2005 21:57
Please respond to
"HttpClient Project"
To
HttpClient Project <ht...@jakarta.apache.org>
cc
Subject
Re: Wiki: Use Cases
Hi Roland,
Just a few thoughts about the new use case resources:
I think we should keep the entry barrier as low as possible. The users
should be able to type away in wiki without having to spend a good deal
of time studying the API redesign proposal or any other resources. I
would prefer to deal with 30% rate of completely nonsensical or
redundant postings rather end up with a few or none at all because
people gave up somewhere half way in the process. We ought to suggest a
structure but we should not insist on people strictly following it.
<http://wiki.apache.org/jakarta-httpclient/UseCases>
Do we really care if a use case falls into any of categories:
Application, Middleware, Engineered or anything else? Use cases can be
semi-structured or un-structured. Eventually the relevant data should
end up in Bugzilla/JIRA in a form of feature requests.
<http://wiki.apache.org/jakarta-httpclient/UseCases/AccessURLs>
This is terrific and very detailed stuff probably worth half a day of
work. I seriously doubt, though, we'll have many submissions of this
quality. We should be realistic and encourage simple postings along this
line: "Wouldn't it be cool if HttpClient 4.0 supported automatic
redirects on POST methods?"
> 1) procedure for new use cases (see a.2)
> Should we encourage users to enter new use cases
> directly in the wiki, or should we ask them to
> always post them to the user mailing list first?
>
The former in my opinion.
> Posting first would help to avoid duplicates, but
> it is a break of media. Users that browse from the
> web page to the wiki could be discouraged by having
> to subscribe to the mailing list.
>
> 2) template for use cases (see b,d)
Absolutely. Very simple and non-intrusive, though.
>
> 3) wording of the RfUC (see a.1)
> The first impression sticks...
>
Looks good to me
> 4) categories for use cases (see c)
> Easy to change, hence lowest importance.
>
See above
> What do you think?
>
You rock
> cheers,
> Roland
Cheers,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Wiki: Use Cases Vol.2
Posted by Roland Weber <RO...@de.ibm.com>.
Hello all,
I have not gotten any feedback on the modified use case pages
in the Wiki. I hope that one or the other will find a few
minutes to have a look at them this weekend:
http://wiki.apache.org/jakarta-httpclient/RequestForUseCases
If I get feedback, I will incorporate it next week. If the pages
are ok as they are, could someone of the project team please open
the floodgates by posting a "Request for Use Cases" to the user
mailing list? I've been wiki-ing on private time, so I don't want
to post the RfUC from my corporate email account.
cheers,
Roland
Roland Weber/Germany/IBM@IBMDE
20.02.2005 10:21
Please respond to
"HttpClient Project"
To
"HttpClient Project" <ht...@jakarta.apache.org>
cc
Subject
Wiki: Use Cases Vol.2
Hello all,
since I didn't get any other feedback, I incorporated Oleg's
suggestions by creating a UseCases/SandBox where people can
easily add use cases without much ado. I put in two examples,
one directly in the sandbox and one as an extra page. Edwin,
thanks for your submission. The RequestForUseCases has become
simpler and there is a new SimpleUseCaseTemplate.
Please have a look at the pages and let me know what you think:
http://wiki.apache.org/jakarta-httpclient/RequestForUseCases
cheers,
Roland
Wiki: Use Cases Vol.2
Posted by Roland Weber <RO...@de.ibm.com>.
Hello all,
since I didn't get any other feedback, I incorporated Oleg's
suggestions by creating a UseCases/SandBox where people can
easily add use cases without much ado. I put in two examples,
one directly in the sandbox and one as an extra page. Edwin,
thanks for your submission. The RequestForUseCases has become
simpler and there is a new SimpleUseCaseTemplate.
Please have a look at the pages and let me know what you think:
http://wiki.apache.org/jakarta-httpclient/RequestForUseCases
cheers,
Roland
Re: Wiki: Use Cases
Posted by Oleg Kalnichevski <ol...@apache.org>.
Hi Roland,
Just a few thoughts about the new use case resources:
I think we should keep the entry barrier as low as possible. The users
should be able to type away in wiki without having to spend a good deal
of time studying the API redesign proposal or any other resources. I
would prefer to deal with 30% rate of completely nonsensical or
redundant postings rather end up with a few or none at all because
people gave up somewhere half way in the process. We ought to suggest a
structure but we should not insist on people strictly following it.
<http://wiki.apache.org/jakarta-httpclient/UseCases>
Do we really care if a use case falls into any of categories:
Application, Middleware, Engineered or anything else? Use cases can be
semi-structured or un-structured. Eventually the relevant data should
end up in Bugzilla/JIRA in a form of feature requests.
<http://wiki.apache.org/jakarta-httpclient/UseCases/AccessURLs>
This is terrific and very detailed stuff probably worth half a day of
work. I seriously doubt, though, we'll have many submissions of this
quality. We should be realistic and encourage simple postings along this
line: "Wouldn't it be cool if HttpClient 4.0 supported automatic
redirects on POST methods?"
> 1) procedure for new use cases (see a.2)
> Should we encourage users to enter new use cases
> directly in the wiki, or should we ask them to
> always post them to the user mailing list first?
>
The former in my opinion.
> Posting first would help to avoid duplicates, but
> it is a break of media. Users that browse from the
> web page to the wiki could be discouraged by having
> to subscribe to the mailing list.
>
> 2) template for use cases (see b,d)
Absolutely. Very simple and non-intrusive, though.
>
> 3) wording of the RfUC (see a.1)
> The first impression sticks...
>
Looks good to me
> 4) categories for use cases (see c)
> Easy to change, hence lowest importance.
>
See above
> What do you think?
>
You rock
> cheers,
> Roland
Cheers,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Wiki: Use Cases
Posted by Oleg Kalnichevski <ol...@apache.org>.
Wow! This is massive. Roland, you rock! Let me chew on it for a couple
of days
Oleg
On Sun, 2005-02-13 at 01:09 +0100, Roland Weber wrote:
> Hello all,
>
> as you have guessed from the Wiki messages,
> I have set up a first take on pages for use cases:
>
> a) RequestForUseCases
> b) UseCaseTemplate
> c) UseCases - list of use cases
> d) UseCases/AccessURLs - example use case
>
> We should have a discussion on these before hitting
> the user list with an RfUC (Request for Use Cases).
> I see the following topics for discussion, in order
> of relevance:
>
> 1) procedure for new use cases (see a.2)
> Should we encourage users to enter new use cases
> directly in the wiki, or should we ask them to
> always post them to the user mailing list first?
>
> Posting first would help to avoid duplicates, but
> it is a break of media. Users that browse from the
> web page to the wiki could be discouraged by having
> to subscribe to the mailing list.
>
> 2) template for use cases (see b,d)
>
> 3) wording of the RfUC (see a.1)
> The first impression sticks...
>
> 4) categories for use cases (see c)
> Easy to change, hence lowest importance.
>
> What do you think?
>
> cheers,
> Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Wiki: Use Cases
Posted by Roland Weber <RO...@de.ibm.com>.
Hello all,
as you have guessed from the Wiki messages,
I have set up a first take on pages for use cases:
a) RequestForUseCases
b) UseCaseTemplate
c) UseCases - list of use cases
d) UseCases/AccessURLs - example use case
We should have a discussion on these before hitting
the user list with an RfUC (Request for Use Cases).
I see the following topics for discussion, in order
of relevance:
1) procedure for new use cases (see a.2)
Should we encourage users to enter new use cases
directly in the wiki, or should we ask them to
always post them to the user mailing list first?
Posting first would help to avoid duplicates, but
it is a break of media. Users that browse from the
web page to the wiki could be discouraged by having
to subscribe to the mailing list.
2) template for use cases (see b,d)
3) wording of the RfUC (see a.1)
The first impression sticks...
4) categories for use cases (see c)
Easy to change, hence lowest importance.
What do you think?
cheers,
Roland
HLCA: collect uses cases?
Posted by Roland Weber <RO...@de.ibm.com>.
Hello all,
I was wondering whether we should collect some use cases as part of
our ongoing discussion on the 4.0 High Level Component Architecture.
Of course we don't have the resources to write down a full set of use
cases starting with "get a page from an HTTP server". I was thinking
along the lines of "really cool things I would want to do with the
HttpClient". We could put such use cases into separate pages in the
wiki and link to them from the HLCA document where appropriate. This
might also encourage a few more people on this list to participate
in the discussions, by contributing use cases. I don't insist on
the term "use cases" either, we could call them "really cool things"
as well :-)
What do you think?
cheers,
Roland
Re: HLCA: generating followup requests
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
> Correct me if I am wrong, essentially you are talking about the
> 'request' scope (HttpMethodExecutor) and the 'session' scope
> (HttpClient), not a hierarchy of contexts per se. Do I understand you
> correctly?
Yes. I see only those two levels that are needed.
> I think HttpContext should always be of request visibility, however some
> specific objects contained in the context may contain information that
> spans across several request/response pairs, such as CookieStore,
> AuthState/AuthScheme. Currently I see this as the simplest solution that
> works, and I like keeping things simple.
So in order to share data between different contexts/sequences, the
context
has to be (pre-)populated with objects that are present in those other
contexts as well.
> What do you think?
>
I think that is a good solution for the problem at hand, and simpler than
dealing with a hierarchy of contexts. Improves data encapsulation, too.
Go ahead, I'm with you now :-)
Btw, I just checked the digest auth scheme to come up with a concrete
example, and it would have been hell using a hierarchy... ;-)
Will you update the design document or should I? After giving others
time to enter this discussion, of course.
cheers,
Roland
Re: HLCA: generating followup requests
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, Feb 07, 2005 at 03:05:25PM +0100, Roland Weber wrote:
> I believe that the authentication sequence handler needs to store some
> data that is relevant only for the current sequence, and some other data
> that is relevant for all requests that happen to be sent to the same
> target host. Hence, it needs a way to indicate whether the data it sets
> should be stored in the local/private or the parent/shared part of the
> context. That has to show up in the interface.
>
Roland,
Correct me if I am wrong, essentially you are talking about the
'request' scope (HttpMethodExecutor) and the 'session' scope
(HttpClient), not a hierarchy of contexts per se. Do I understand you
correctly?
I think HttpContext should always be of request visibility, however some
specific objects contained in the context may contain information that
spans across several request/response pairs, such as CookieStore,
AuthState/AuthScheme. Currently I see this as the simplest solution that
works, and I like keeping things simple.
What do you think?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: generating followup requests
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
> The point I am trying to get across is that no matter how the context is
> structured internally (as a hierarchy of contexts, for instance) this
> should not affect the interface. Does the HTTP filter really have to
> care whether a certain attribute is defined at the local or parent
> level? I am just trying to think of a legitimate use case.
I believe that the authentication sequence handler needs to store some
data that is relevant only for the current sequence, and some other data
that is relevant for all requests that happen to be sent to the same
target host. Hence, it needs a way to indicate whether the data it sets
should be stored in the local/private or the parent/shared part of the
context. That has to show up in the interface.
> As to the http-async stuff, can't we subclass the HttpContext with async
> specific methods instead of imposing a more generic and complex
> interface upon all implementations?
It's not specific to http-async. Async is only where the idea becomes
most obvious, because in the synchronous case you can store all app
level data in variables.
If I am mistaken and there is no need for a local context within the
HttpClient, we can keep it all simple and use/invent a different mechanism
for local application data. And that mechanism could well be implemented
just in http-async, for example as part of the handles there. No problem.
The two cases where I can see/imagine an internal need for local context
are authentication and tracking of message relations, where the tracking
is still just an idea that keeps bugging me. So if we don't need local
context in the authentication case, and no-one else comes up with a
different use case where it is needed, I won't complain about using the
simple version ever again :-)
cheers,
Roland
cheers,
Roland
Re: HLCA: generating followup requests
Posted by Oleg Kalnichevski <ol...@apache.org>.
Hi Roland,
The point I am trying to get across is that no matter how the context is
structured internally (as a hierarchy of contexts, for instance) this
should not affect the interface. Does the HTTP filter really have to
care whether a certain attribute is defined at the local or parent
level? I am just trying to think of a legitimate use case.
As to the http-async stuff, can't we subclass the HttpContext with async
specific methods instead of imposing a more generic and complex
interface upon all implementations?
Oleg
On Mon, Feb 07, 2005 at 02:30:00PM +0100, Roland Weber wrote:
> Hi Oleg,
>
> > > rather:
> > >
> > > interface HttpMessage {
> > >
> > > HttpContext getContext();
> > >
> > > }
> > >
> >
> > Do we really need to couple the HttpMessage and HttpContext?
> >
> > >
> > > interface HttpSequenceHandler {
> > >
> > > HttpRequest process(HttpRequest, HttpResponse);
> > >
> >
> > I would rather retrieve HttpRequest from HttpContext, and not the other
> > way around, but tastes differ ;-)
>
> I guess it all has to do with the hierarchical context I have in mind.
> To me, every request is the start of a sequence that has a local context
> shared only be the requests and responses in that sequence. Hence I
> want to get access to the context from the message. In particular, I
> am thinking of the asynchronous case, where one part of the application
> is generating requests, and another part is dealing with the responses.
> The latter should have access to the context set be the former. But I
> can imagine different ways to pass the context than having it accessible
> directly from the message.
>
> >
> > Againt, the exact details of interfaces should probably be decided at a
> > later stage, when we finally get down to coding.
> >
> Sure. But the usage pattern for the context might be more than an
> implementation detail. Then again, it might not :-)
>
> cheers,
> Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: generating followup requests
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
> > rather:
> >
> > interface HttpMessage {
> >
> > HttpContext getContext();
> >
> > }
> >
>
> Do we really need to couple the HttpMessage and HttpContext?
>
> >
> > interface HttpSequenceHandler {
> >
> > HttpRequest process(HttpRequest, HttpResponse);
> >
>
> I would rather retrieve HttpRequest from HttpContext, and not the other
> way around, but tastes differ ;-)
I guess it all has to do with the hierarchical context I have in mind.
To me, every request is the start of a sequence that has a local context
shared only be the requests and responses in that sequence. Hence I
want to get access to the context from the message. In particular, I
am thinking of the asynchronous case, where one part of the application
is generating requests, and another part is dealing with the responses.
The latter should have access to the context set be the former. But I
can imagine different ways to pass the context than having it accessible
directly from the message.
>
> Againt, the exact details of interfaces should probably be decided at a
> later stage, when we finally get down to coding.
>
Sure. But the usage pattern for the context might be more than an
implementation detail. Then again, it might not :-)
cheers,
Roland
Re: HLCA: generating followup requests
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, Feb 07, 2005 at 01:59:57PM +0100, Roland Weber wrote:
Hi Roland
>
> I would add these:
>
> public final static int SCOPE_LOCAL // default
> public final static int SCOPE_PARENT // uplevel 1
>
> void setAttribute(String, Object, int scope)
> HttpContext getParent()
>
>
I do not see a problem with that. This said, I am still not entirely
sure we need the hierarchical context. I was going to deal with this
issue in a separate mail.
>
> rather:
>
> interface HttpMessage {
>
> HttpContext getContext();
>
> }
>
Do we really need to couple the HttpMessage and HttpContext?
>
> interface HttpSequenceHandler {
>
> HttpRequest process(HttpRequest, HttpResponse);
>
I would rather retrieve HttpRequest from HttpContext, and not the other
way around, but tastes differ ;-)
Againt, the exact details of interfaces should probably be decided at a
later stage, when we finally get down to coding.
Cheers,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: generating followup requests
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
see inline.
> So, how about this?
>
> interface HttpContext {
>
> Object getAttribute(String);
> void setAttribute(String, Object);
>
> }
I would add these:
public final static int SCOPE_LOCAL // default
public final static int SCOPE_PARENT // uplevel 1
void setAttribute(String, Object, int scope)
HttpContext getParent()
>
> interface HttpFilter {
>
> void preprocess(HttpRequest, HttpContext);
> void postprocess(HttpResponse, HttpContext);
>
> }
rather:
interface HttpMessage {
HttpContext getContext();
}
interface HttpFilter {
void preprocess(HttpRequest);
void postprocess(HttpResponse);
// or (HttpMessage), for the server side?
}
>
> (2) The same HttpContext interface may aslo be used by the HttpClient
>
> (3) I do agree with you that the existing HttpFilter framework is not
> sufficient to implement a fully functional redirect and authentication
> handlers as these handlers may need to issue additional requests or
> convert a request of one type to that of another. In other words one
> request to one response relationship is not applicable here.
>
> (4) The HttpSequence can solve the problem quite elegantly
>
> interface HttpSequenceHandler {
>
> HttpRequest process(HttpResponse, HttpContext);
>
> }
interface HttpSequenceHandler {
HttpRequest process(HttpRequest, HttpResponse);
}
>
> This framework seems simple yet flexible enough to accommodate for all
> the use cases I know of. It is generic enough to be put into
> http-common, leaving the details of concrete implementations up to
> http-client and http-auth.
>
> What do you think?
>
> Oleg
>
Re: HLCA: generating followup requests
Posted by Oleg Kalnichevski <ol...@apache.org>.
Mike, Roland
To sum things up
(1) We do need a notion of an execution context for HttpFilters to be
any use
Different filters may need to have access to different type of runtime
data. For instance, some filters may need to have access to the cookie
store, the host config, the authentication context, and what not. The
post-processing filter may also need access to the original request
object. In order to avoid an unwieldy method signature we do need a
means of passing all that information to the filter. The use of a
context of a sort is probably the most common pattern to solve the
problem
So, how about this?
interface HttpContext {
Object getAttribute(String);
void setAttribute(String, Object);
}
interface HttpFilter {
void preprocess(HttpRequest, HttpContext);
void postprocess(HttpResponse, HttpContext);
}
(2) The same HttpContext interface may aslo be used by the HttpClient
(3) I do agree with you that the existing HttpFilter framework is not
sufficient to implement a fully functional redirect and authentication
handlers as these handlers may need to issue additional requests or
convert a request of one type to that of another. In other words one
request to one response relationship is not applicable here.
(4) The HttpSequence can solve the problem quite elegantly
interface HttpSequenceHandler {
HttpRequest process(HttpResponse, HttpContext);
}
This framework seems simple yet flexible enough to accommodate for all
the use cases I know of. It is generic enough to be put into
http-common, leaving the details of concrete implementations up to
http-client and http-auth.
What do you think?
Oleg
On Sun, Feb 06, 2005 at 02:26:15PM -0500, Michael Becke wrote:
> The request context is a good idea. In combination with the filters I
> think this would be enough to handle authentication. As Roland
> mentioned a filter should only need the current state and request URI
> to determine what to do. We would just need a way to signal that
> request should be retried. Would there be other uses for context other
> than authentication?
>
> In regard to redirects I'm not sure there is a way to handle this
> entirely with filters. The big problem here would be handling
> redirects in response to a POST, not only would we need to rewrite the
> request URI, but we need a new method type.
>
> Mike
>
> On Feb 6, 2005, at 8:01 AM, Roland Weber wrote:
>
> >Hi Oleg,
> >
> >>We may think of an additional
> >>abstraction layer in a form of HttpContext, which would enable the
> >>redirect handler to reset the authentication process without being
> >>directly coupled with any of the authentication classes.
> >
> >I like the idea of a context. I assume we will have an HttpAuthFilter
> >responsible for inserting Authorization and Proxy-Authorization headers
> >into requests, and an AuthenticationChallengeHandler in whatever form,
> >which provides the authentication data for the filter. A context would
> >be a good way for these two associated objects to share data. It is
> >also a good way to share data across requests, like authentication
> >challenges.
> >To avoid bringing actual authentication dependencies into http-common,
> >an approach similar to {s|g}etAttribute in the Servlet API could be
> >taken. The context information from the original request can be made
> >available in the associated responses and followup requests. This
> >would make the context useful for applications as well.
> >
> >I still think that an authentication handler should itself detect
> >state changes due to changing URLs, rather than rely on an explicit
> >reset by a redirect handler. Like in a browser, the authentication
> >state should keep track of the current authentication realms from
> >which challenges have already been received, and the URL domains to
> >which these realms extend.
> >
> >cheers,
> > Roland
>
>
> ---------------------------------------------------------------------
> 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: HLCA: generating followup requests
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Michael,
> The request context is a good idea. In combination with the filters I
> think this would be enough to handle authentication. As Roland
> mentioned a filter should only need the current state and request URI
> to determine what to do. We would just need a way to signal that
> request should be retried.
I wouldn't mix retry and filters. Filters should take care of pre- and
postprocessing a single request, a different (generic) interface should
take care of generating followup requests (that is, retry in absence of
a communication problem). After all, that's how this thread started :-)
HttpSequenceHandler or HttpSequencer are the latest suggestions for a
name.
> Would there be other uses for context other
> than authentication?
I expect we'll have an HttpFilter that sets cookies in a request and a
different HttpFilter that processes set-cookie headers in a response.
Both use a cookie store, but instead of having a reference to the
cookie store in the filters themselves, I would keep the cookie store
in the context. That way, the filter implementations are stateless.
I would also allow applications to store data in the context, like a
sequence number for requests. By finding that sequence number in the
response, it is easy to determine what to do with the response. That's
especially useful if you send several requests asynchronously.
I believe we will need a hierarchical context, with a parent context
that applies to unrelated requests from the same client, similar in
purpose to the HttpState currently. The child contexts would apply to
a single sequence of requests/responses.
The parent context is the place for the cookie store and authentication
data (see below), the child context is for application sequence numbers
or other reference data, and for tracking of relations between requests
and responses. (Remember my mail about that a while back?)
> In regard to redirects I'm not sure there is a way to handle this
> entirely with filters. The big problem here would be handling
> redirects in response to a POST, not only would we need to rewrite the
> request URI, but we need a new method type.
See above. Redirects are another case for the HttpSequencer.
> [from a different mail:]
>> [...]
> I think it may depend on the type of authentication. Basic doesn't
> really need any context.
A browser will keep track of the basic auths that have already been
performed after receiving a 401 or 407 response. If another request
is sent to the same realm, the (proxy) authorization header is inserted
immediately, instead of waiting for another 40x response and retrying
the request. I would like to use the parent context for implementing
a similar behavior. But I don't know how this is handled in the current
implementation.
> NTLM on the other hand requires all sorts of
> context. Not only does it need request context for the sequence of
> challenges, but if I remember correctly it's actually a connection
> based authentication scheme.
I was afraid you'd say that. Connection based will become really ugly
in combination with async, or at least it has that potential. In general,
NTLM sounds like a case for the child context, or parent as well as
child context for different values that need to be remembered.
cheers,
Roland
Re: HLCA: generating followup requests
Posted by Michael Becke <be...@u.washington.edu>.
The request context is a good idea. In combination with the filters I
think this would be enough to handle authentication. As Roland
mentioned a filter should only need the current state and request URI
to determine what to do. We would just need a way to signal that
request should be retried. Would there be other uses for context other
than authentication?
In regard to redirects I'm not sure there is a way to handle this
entirely with filters. The big problem here would be handling
redirects in response to a POST, not only would we need to rewrite the
request URI, but we need a new method type.
Mike
On Feb 6, 2005, at 8:01 AM, Roland Weber wrote:
> Hi Oleg,
>
>> We may think of an additional
>> abstraction layer in a form of HttpContext, which would enable the
>> redirect handler to reset the authentication process without being
>> directly coupled with any of the authentication classes.
>
> I like the idea of a context. I assume we will have an HttpAuthFilter
> responsible for inserting Authorization and Proxy-Authorization headers
> into requests, and an AuthenticationChallengeHandler in whatever form,
> which provides the authentication data for the filter. A context would
> be a good way for these two associated objects to share data. It is
> also a good way to share data across requests, like authentication
> challenges.
> To avoid bringing actual authentication dependencies into http-common,
> an approach similar to {s|g}etAttribute in the Servlet API could be
> taken. The context information from the original request can be made
> available in the associated responses and followup requests. This
> would make the context useful for applications as well.
>
> I still think that an authentication handler should itself detect
> state changes due to changing URLs, rather than rely on an explicit
> reset by a redirect handler. Like in a browser, the authentication
> state should keep track of the current authentication realms from
> which challenges have already been received, and the URL domains to
> which these realms extend.
>
> cheers,
> Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: HLCA: generating followup requests
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
> We may think of an additional
> abstraction layer in a form of HttpContext, which would enable the
> redirect handler to reset the authentication process without being
> directly coupled with any of the authentication classes.
I like the idea of a context. I assume we will have an HttpAuthFilter
responsible for inserting Authorization and Proxy-Authorization headers
into requests, and an AuthenticationChallengeHandler in whatever form,
which provides the authentication data for the filter. A context would
be a good way for these two associated objects to share data. It is
also a good way to share data across requests, like authentication
challenges.
To avoid bringing actual authentication dependencies into http-common,
an approach similar to {s|g}etAttribute in the Servlet API could be
taken. The context information from the original request can be made
available in the associated responses and followup requests. This
would make the context useful for applications as well.
I still think that an authentication handler should itself detect
state changes due to changing URLs, rather than rely on an explicit
reset by a redirect handler. Like in a browser, the authentication
state should keep track of the current authentication realms from
which challenges have already been received, and the URL domains to
which these realms extend.
cheers,
Roland
Re: HLCA: generating followup requests
Posted by Oleg Kalnichevski <ol...@apache.org>.
Hi Roland,
Here is my take. Overall I find FollowupHandler and FollowupHandlerChain
to be a good idea worth exploring. (Can HttpSequenceHandler be
potentially a better name, though?)
As to a better componentization, I am not entirely convinced
The trouble is that I see no clear way to separate redirect handling and
authentication handling, as the redirect handler may need to reset the
state of the authentication process. At the moment I see no way around a
limited redirect code duplication if we still want to keep all the
authentication aspects out of http-common. We may think of an additional
abstraction layer in a form of HttpContext, which would enable the
redirect handler to reset the authentication process without being
directly coupled with any of the authentication classes. However, I am
unable to say at this point if this is feasible.
Oleg
On Fri, 2005-02-04 at 16:19 +0100, Roland Weber wrote:
> Hello folks,
>
> I've been thinking about authentication and the responsibilities
> for handling authentication challenges. Right now, http-common
> and the HttpMethodDirector are explicitly not responsible for
> dealing with followup requests. http-auth holds code for dealing
> with authentication challenges, but the responsibility for
> generating and executing a followup request lies with http-client.
>
> There are two things that bug me about this approach:
>
> 1) Someone who wants to use http-common and http-auth cannot do
> so without either using http-client as well or duplicating
> code from http-client
> 2) How does http-auth integrate with http-async? By duplicating
> code from http-client in http-async?
>
> In other words, I don't think our architecture is really
> componentized at this point. And here is my idea on how to
> change that:
>
> Let's introduce a callback interface in http-common, say
> "FollowupHandler". A FollowupHandler gets an HttpResponse and
> the HttpRequest that generated the response to decide whether
> a followup request is needed. If so, it can also build the
> new request. Note that the handler does *not* send the
> followup request, it only generates it.
> HttpMethodExecutor, after receiving a response, queries the
> FollowupHandler whether another request needs to be sent. If
> so, it handles the followup request. That is similar to the
> error case, where the HttpRequestRetryHandler decides whether
> the original request should be sent again.
> FollowupHandlerChain implements FollowupHandler and asks a
> list of individual handlers until one of them decides that
> a followup request needs to be sent, or none of them does.
>
> So far, the functionality is generic and does not put too
> much additional complexity in http-common. Now we need some
> actual followup handlers:
>
> - AuthChallengeHandler in http-auth, for handling authentication
> challenges from proxies and target servers. There is not much
> point in separating these two cases into different classes.
> - RedirectHandler (in http-common?) for handling redirects.
>
> In http-async, the same interfaces and handler implementations
> can be used. Remember that http-async is meant to replace
> HttpMethodDirector for asynchronous communication, and there-
> fore needs to cover the same functionality. This can be easily
> achieved using such handlers.
>
> The responsibility of http-client will be to collect an
> appropriate FollowupHandlerChain.
>
>
> With these changes, an application developer can easily combine
> http-common and http-auth without using http-client. It is
> also possible to combine http-common, http-async and http-auth.
> How http-async and http-client can be made to plug and play is
> a different problem.
>
>
> What do you think?
>
> cheers,
> Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
HLCA: generating followup requests
Posted by Roland Weber <RO...@de.ibm.com>.
Hello folks,
I've been thinking about authentication and the responsibilities
for handling authentication challenges. Right now, http-common
and the HttpMethodDirector are explicitly not responsible for
dealing with followup requests. http-auth holds code for dealing
with authentication challenges, but the responsibility for
generating and executing a followup request lies with http-client.
There are two things that bug me about this approach:
1) Someone who wants to use http-common and http-auth cannot do
so without either using http-client as well or duplicating
code from http-client
2) How does http-auth integrate with http-async? By duplicating
code from http-client in http-async?
In other words, I don't think our architecture is really
componentized at this point. And here is my idea on how to
change that:
Let's introduce a callback interface in http-common, say
"FollowupHandler". A FollowupHandler gets an HttpResponse and
the HttpRequest that generated the response to decide whether
a followup request is needed. If so, it can also build the
new request. Note that the handler does *not* send the
followup request, it only generates it.
HttpMethodExecutor, after receiving a response, queries the
FollowupHandler whether another request needs to be sent. If
so, it handles the followup request. That is similar to the
error case, where the HttpRequestRetryHandler decides whether
the original request should be sent again.
FollowupHandlerChain implements FollowupHandler and asks a
list of individual handlers until one of them decides that
a followup request needs to be sent, or none of them does.
So far, the functionality is generic and does not put too
much additional complexity in http-common. Now we need some
actual followup handlers:
- AuthChallengeHandler in http-auth, for handling authentication
challenges from proxies and target servers. There is not much
point in separating these two cases into different classes.
- RedirectHandler (in http-common?) for handling redirects.
In http-async, the same interfaces and handler implementations
can be used. Remember that http-async is meant to replace
HttpMethodDirector for asynchronous communication, and there-
fore needs to cover the same functionality. This can be easily
achieved using such handlers.
The responsibility of http-client will be to collect an
appropriate FollowupHandlerChain.
With these changes, an application developer can easily combine
http-common and http-auth without using http-client. It is
also possible to combine http-common, http-async and http-auth.
How http-async and http-client can be made to plug and play is
a different problem.
What do you think?
cheers,
Roland
HLCA: SingleProxy extending SimpleProxyChain
Posted by Roland Weber <RO...@de.ibm.com>.
Hello folks,
in our High Level Component Architecture for the 4.0 API at
http://wiki.apache.org/jakarta-httpclient/HttpClientApiRedesign
I have noticed these items in http-common:
> SimpleProxyChain class implementing ProxyChain.
> List of HttpProxyHost objects.
>
> SingleProxy class extending SimpleProxyChain.
> For use when a single proxy server is used.
It seems odd to me to derive the single-object implementation
from the list-of-objects implementation. At least I have
always run into problems when I tried to restrict base class
functionality in a derived class. That's just not what the
(contravariant) inheritance mechanism is meant for.
If we expect signifcant code re-use between the two different
implementations, let's introduce an abstract base class. If
not, let's just have a SingleProxy implementing ProxyChain
without a base class.
What do you think?
cheers,
Roland
HLCA: http entities - take two
Posted by Roland Weber <RO...@de.ibm.com>.
Hello again,
here is take two on moving http entities into their own
class hierarchy. The Decorator pattern for input/output
does not really fit, because writing or reading an entity
is not a functionality that can be implemented without
internal knowledge of the entity itself.
What I intend is closer to the Strategy pattern. There
is a strategy for writing an entity, and one for reading
an entity. The various Ic and Og classes implement such
strategies for a particular type of entity.
To reduce the number of classes, I have moved both strategies
into one for the simple in-memory entity types. I also dropped
the BasicOgEntity and BasicIcEntity classes because I don't
know what would actually be implemented there and because
I can't derive from both of them at the same time.
Here is what it looks like now, with suggestions for the
methods that go into some of the classes and interfaces.
I'm old-fashioned, so it's java.io rather than java.nio
for the time being ;-)
http-common
HttpMessage as base interface for HttpRequest, HttpResponse
- getHeader(), setHeader()
HttpEntity interface
- getContentLength(), getContentType()
HttpOutgoingEntity interface extends HttpEntity
- isRepeatable(), writeTo(OutputStream)
HttpIncomingEntity interface extends HttpEntity
- readFrom(HttpMessage, InputStream) ?
(or have that functionality in a constructor)
BasicEntity implements HttpEntity
- public getContentLength(), getContentType()
- protected setContentLength(), setContentType()
StringEntity extends BasicEntity
implements HttpOutgoingEntity, HttpIncomingEntity
ByteArrayEntity extends BasicEntity
implements HttpOutgoingEntity, HttpIncomingEntity
InputStreamOgEntity extends BasicEntity
implements HttpOutgoingEntity
OutputStreamIcEntity extends BasicEntity
implements HttpIncomingEntity
http-client
FormDataEntity extends BasicEntity
implements HttpOutgoingEntity, HttpIncomingEntity
uses commons-codec, therefore in http-client
MultipartOgEntity extends BasicEntity
implements HttpOutgoingEntity
based on commons-codec or code in o.a.c.hc.methods.multipart
MultipartIcEntity extends BasicEntity
implements HttpIncomingEntity
based on commons-codec (only if available)
alternative implementations based on javax.mail or
commons-fileupload can be kept in a "contrib" component
once they are contributed
What do you think?
cheers,
Roland
HLCA: http entities
Posted by Roland Weber <RO...@de.ibm.com>.
Hello folks,
as I have briefly mentioned in a previous mail, I would like to
move the handling of HTTP entities into dedicated classes,
instead of having it in method implementations. The main
reasons for this are:
1. entities have to be put into HTTP responses as well, though
these tend to be more simple than the multipart entities
frequently found in requests
2. all entity enclosing methods (in particular POST and PUT)
should provide identical means for defining entities, without
having to duplicate code
2. on the server side, a method will provide access to the
enclosed entity but does not allow to define it
In the light of Oleg's attempts to make request and response
objects useful on both client and server side, I believe that
separate entity handling classes will simplify re-use. And
here is my first take on it:
http-common:
HttpEntity interface
HttpOutgoingEntity extends HttpEntity (was: RequestEntity)
HttpIncomingEntity extends HttpEntity
BasicEntity implements HttpEntity
BasicOgEntity extends BasicEntity implements HttpOutgoingEntity
BasicIcEntity extends BasicEntity implements HttpIncomingEntity
StringOgEntity extends BasicOgEntity
ByteArrayOgEntity extends BasicOgEntity
InputStreamOgEntity extends BasicOgEntity
FormDataOgEntity extends BasicOgEntity
based on code currently in PostMethod
OutputStreamIcEntity extends BasicIcEntity
ByteArrayIcEntity extends BasicIcEntity
(Rename EntityEnclosingMethod to something that can
reasonably be implemented by HttpResponse as well?)
http-multipart:
MultipartOgEntity extends BasicOgEntity
based on current code in o.a.c.hc.methods.multipart
(Part, PartBase, StringPart, ByteArrayPart, FilePart
PartSource, ByteArrayPartSource, FilePartSource)
MultipartIcEntity extends BasicIcEntity
based on Commons FileUpload - as a future extension
What do you think? I will take care of updating the
design document once we have reached a consensus.
cheers,
Roland
Re: HLCA: http-tunnel
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
> The trouble is that any sort meaningful tunneling component most likely
> would require at least rudimentary HTTP authentication support (http-
> auth) and ability to retry HTTP requests (HttpMethodExecutor). Without
> these features ProxyConnectMethod and HttpProxyHost would be of very
> marginal use only.
That's why we are working on a componentized architecture, right?
If people need authentication in addition to the simple stuff, they
add http-auth to their dependencies.
Should we move the AuthChallengeHandler and StdAuthChallengeHandler
to http-auth? HttpMethodExecutor is available in http-common anyway.
I feel comfortable with Michael's proposal of moving the proxy stuff
to http-common rather than introducing a separate component. Since
we don't intend to provide explicit tunneling support except for
HTTP and HTTPS, a component may be overblown.
cheers,
Roland
Re: HLCA: http-tunnel
Posted by Oleg Kalnichevski <ol...@apache.org>.
Roland,
The trouble is that any sort meaningful tunneling component most likely
would require at least rudimentary HTTP authentication support (http-
auth) and ability to retry HTTP requests (HttpMethodExecutor). Without
these features ProxyConnectMethod and HttpProxyHost would be of very
marginal use only.
What would you say if we moved HttpHost to http-common, kept
HttpMethodExecutor in http-common and moved ProxyConnectMethod and
HttpProxyHost to http-auth?
Oleg
On Sat, 2005-01-15 at 13:51 +0100, Roland Weber wrote:
> Hello folks,
>
> since the http-common component is meant to be useful
> by it's own for simple HTTP communication, we should
> give a little thought to those that might want to work on
> that simple level. As soon as they have to communicate
> through a proxy, they get a dependency on the http-client
> component, which depends on several other components.
> The dependencies seem even more excessive for people
> who only want to tunnel an application specific protocol
> through an HTTP proxy.
>
> What do you think about a new component for the
> proxy/tunneling support currently listed in http-client?
>
> * http-tunnel depends on http-common
> - ProxyConnectMethod implementing HttpRequest
> ? HttpProxyHost (only if HttpHost is moved to
> http-common, to avoid dependency on http-client)
>
>
> cheers,
> Roland
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org