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 2003/11/06 23:40:21 UTC
HttpClient Revolutions
Folks,
This is one of those days when my frustration with the existing
HttpClient architecture reaches the point when I can hardly fight off
the idea of stating a fork at SourceForge in order to finally get the
very basic things right. I am really getting tired of patching the
deficient architecture and bending it in all sorts of creative ways.
I was trying to provide a fix for the bug that I introduced with one of
my recent patches (authentication headers created by HttpMethodDirector
end up removed in HttpMethodBase). The nasty thing is that since headers
can be added to the HTTP method in several places, it is not quite clear
at what point auto-generated headers are safe to be removed. If the
auto-generated are cleaned up in the authentication/redirect loop, then
they are not cleaned up in case of automatic recovery from a transport
exception. As a result cookie headers can be duplicated. If the
auto-generated headers are cleaned inside the retry loop, authentication
headers are not re-generated in case of the method retry.
So, once again the real trouble is the ugly design of the HttpMethod
interface/HttpMethodBase class. The decision to recreate request headers
every time the method is being executed was ill-conceived, not to
mention that this is not quite efficient.
I strongly believe that the process of request assembly and request
execution should be decoupled. I suggest the
generateRequstHeaders(HttpState, HttpConnection) method be added to the
HttpMethod interface. The only problem that concerns me is that this may
be too much of a change for 2.1 release, and I once again will end up
accused of all sorts of things ranging from not caring about backward
compatibility to deliberately breaking other people's stuff. Actually
applications that only use public HttpClient APIs will not be affected,
but classes implementing HttpMethod interface will be broken.
Let me know what's your feeling about this
I'm off to bed
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: HttpClient Revolutions
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
You asked for opinions, here's mine...
There is no point maintaining broken stuff, it just leads to more real world
misery. Backwards compatible or not. I'd rather if it break at
compile/dynamic link time, not runtime (with broken stuff). I want a
ubiquitous HttpClient I can rely upon, and it needs to be stable, so it
needs to be maintainable, hence clean. Your time is better spent making this
clean than fighting mistakes.
Short term pain, long term gain -- that's my view! [I've recently started
two re-works, clean-ups -- and I've gotta say ... Yum! Nothing feels
better...]
regards,
Adam
P.S. Why can't HttpClient jump to a 3.0? Who cares about time and numbers?
In a month [or whatever] folks will look back on working system and not know
the difference. Is HttpClient really so ubiquitous it couldn't make a jump?
----- Original Message -----
From: "Oleg Kalnichevski" <ol...@apache.org>
To: "Jakarata Commons HttpClient mailing list"
<co...@jakarta.apache.org>
Sent: Thursday, November 06, 2003 3:40 PM
Subject: HttpClient Revolutions
> Folks,
> This is one of those days when my frustration with the existing
> HttpClient architecture reaches the point when I can hardly fight off
> the idea of stating a fork at SourceForge in order to finally get the
> very basic things right. I am really getting tired of patching the
> deficient architecture and bending it in all sorts of creative ways.
>
> I was trying to provide a fix for the bug that I introduced with one of
> my recent patches (authentication headers created by HttpMethodDirector
> end up removed in HttpMethodBase). The nasty thing is that since headers
> can be added to the HTTP method in several places, it is not quite clear
> at what point auto-generated headers are safe to be removed. If the
> auto-generated are cleaned up in the authentication/redirect loop, then
> they are not cleaned up in case of automatic recovery from a transport
> exception. As a result cookie headers can be duplicated. If the
> auto-generated headers are cleaned inside the retry loop, authentication
> headers are not re-generated in case of the method retry.
>
> So, once again the real trouble is the ugly design of the HttpMethod
> interface/HttpMethodBase class. The decision to recreate request headers
> every time the method is being executed was ill-conceived, not to
> mention that this is not quite efficient.
>
> I strongly believe that the process of request assembly and request
> execution should be decoupled. I suggest the
> generateRequstHeaders(HttpState, HttpConnection) method be added to the
> HttpMethod interface. The only problem that concerns me is that this may
> be too much of a change for 2.1 release, and I once again will end up
> accused of all sorts of things ranging from not caring about backward
> compatibility to deliberately breaking other people's stuff. Actually
> applications that only use public HttpClient APIs will not be affected,
> but classes implementing HttpMethod interface will be broken.
>
> Let me know what's your feeling about this
>
> I'm off to bed
>
> Oleg
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: HttpClient Revolutions
Posted by Ortwin Glück <or...@nose.ch>.
I have a lot of sympathy for you and your ideas, Oleg. As I mentioned
earlier, I don't mind at all if the HttpClient API will be completely
different in the next release. In my opinion there is no point in
keeping broken stuff for the sake of backward compatibility. Just give
the kid the right name and nobody will ever complain about compatibility
issues...
Odi
ps. I like that subject line :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: HttpClient Revolutions
Posted by Michael Becke <be...@u.washington.edu>.
Hi Oleg,
No need to be frustrated. As has been the case since we started work
on "2.1" our plan for backwards compatibility has been to keep as much
as we can. We have already made a number of changes in 2.1 that could
potentially cause trouble for users. I think must continue to try to
make as few API breaking changes as possible. In the end we will call
it either 2.1, 2.5, or 3.0 depending on the changes.
As for this current question I haven't looked at it closely enough to
offer anything useful, but I will think about it some tomorrow.
Mike
On Nov 6, 2003, at 5:40 PM, Oleg Kalnichevski wrote:
> Folks,
> This is one of those days when my frustration with the existing
> HttpClient architecture reaches the point when I can hardly fight off
> the idea of stating a fork at SourceForge in order to finally get the
> very basic things right. I am really getting tired of patching the
> deficient architecture and bending it in all sorts of creative ways.
>
> I was trying to provide a fix for the bug that I introduced with one of
> my recent patches (authentication headers created by HttpMethodDirector
> end up removed in HttpMethodBase). The nasty thing is that since
> headers
> can be added to the HTTP method in several places, it is not quite
> clear
> at what point auto-generated headers are safe to be removed. If the
> auto-generated are cleaned up in the authentication/redirect loop, then
> they are not cleaned up in case of automatic recovery from a transport
> exception. As a result cookie headers can be duplicated. If the
> auto-generated headers are cleaned inside the retry loop,
> authentication
> headers are not re-generated in case of the method retry.
>
> So, once again the real trouble is the ugly design of the HttpMethod
> interface/HttpMethodBase class. The decision to recreate request
> headers
> every time the method is being executed was ill-conceived, not to
> mention that this is not quite efficient.
>
> I strongly believe that the process of request assembly and request
> execution should be decoupled. I suggest the
> generateRequstHeaders(HttpState, HttpConnection) method be added to the
> HttpMethod interface. The only problem that concerns me is that this
> may
> be too much of a change for 2.1 release, and I once again will end up
> accused of all sorts of things ranging from not caring about backward
> compatibility to deliberately breaking other people's stuff. Actually
> applications that only use public HttpClient APIs will not be affected,
> but classes implementing HttpMethod interface will be broken.
>
> Let me know what's your feeling about this
>
> I'm off to bed
>
> Oleg
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: HttpClient Revolutions
Posted by Oleg Kalnichevski <ol...@apache.org>.
Odi, Roland, Mike, and Adam
Thanks for the feedback. I took another look at the code this morning
and had to concede that any half-measure would hardly make things better
(or cleaner). Until HttpMethod interface is split into
HttpRequest/HttpResponse pair, decoupling of request assembly and
request execution logic does not make a lot of sense.
No revolution for now. Especially on November the 7th. The previous one
did little good.
I'll provide a fix for the bug sometime this weekend. No API changes
will be involved.
Cheers
Oleg
On Fri, 2003-11-07 at 07:41, Roland Weber wrote:
> Hi Oleg,
>
> the urge to take something apart and put it back together
> the way it should be is something I can sympathize with.
> But, as Mike pointed out, the idea was to keep the bad
> stuff for this release and do the overhaul for the next one.
> I think if you can hang on through these hard times, you'll
> have even more fun once you get started on 3.0.
>
> As for the problem at hand, here is one suggestion:
> Currently, you are keeping all headers in the same place
> and try to throw out the auto-generated ones to clean up.
> Instead, you could collect the manually set headers in a
> dedicated place. When headers get generated, you start
> by copying them into an empty header set, then adding
> those that need to be generated to that new set. Cleanup
> reduces to throwing away the generated set.
>
> cheer up!
> Roland
>
>
>
>
>
>
> Oleg Kalnichevski <ol...@apache.org>
> 06.11.2003 23:40
> Please respond to "Commons HttpClient Project"
>
> To: Jakarata Commons HttpClient mailing list
> <co...@jakarta.apache.org>
> cc:
> Subject: HttpClient Revolutions
>
>
> Folks,
> This is one of those days when my frustration with the existing
> HttpClient architecture reaches the point when I can hardly fight off
> the idea of stating a fork at SourceForge in order to finally get the
> very basic things right. I am really getting tired of patching the
> deficient architecture and bending it in all sorts of creative ways.
>
> I was trying to provide a fix for the bug that I introduced with one of
> my recent patches (authentication headers created by HttpMethodDirector
> end up removed in HttpMethodBase). The nasty thing is that since headers
> can be added to the HTTP method in several places, it is not quite clear
> at what point auto-generated headers are safe to be removed. If the
> auto-generated are cleaned up in the authentication/redirect loop, then
> they are not cleaned up in case of automatic recovery from a transport
> exception. As a result cookie headers can be duplicated. If the
> auto-generated headers are cleaned inside the retry loop, authentication
> headers are not re-generated in case of the method retry.
>
> So, once again the real trouble is the ugly design of the HttpMethod
> interface/HttpMethodBase class. The decision to recreate request headers
> every time the method is being executed was ill-conceived, not to
> mention that this is not quite efficient.
>
> I strongly believe that the process of request assembly and request
> execution should be decoupled. I suggest the
> generateRequstHeaders(HttpState, HttpConnection) method be added to the
> HttpMethod interface. The only problem that concerns me is that this may
> be too much of a change for 2.1 release, and I once again will end up
> accused of all sorts of things ranging from not caring about backward
> compatibility to deliberately breaking other people's stuff. Actually
> applications that only use public HttpClient APIs will not be affected,
> but classes implementing HttpMethod interface will be broken.
>
> Let me know what's your feeling about this
>
> I'm off to bed
>
> Oleg
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: HttpClient Revolutions
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
the urge to take something apart and put it back together
the way it should be is something I can sympathize with.
But, as Mike pointed out, the idea was to keep the bad
stuff for this release and do the overhaul for the next one.
I think if you can hang on through these hard times, you'll
have even more fun once you get started on 3.0.
As for the problem at hand, here is one suggestion:
Currently, you are keeping all headers in the same place
and try to throw out the auto-generated ones to clean up.
Instead, you could collect the manually set headers in a
dedicated place. When headers get generated, you start
by copying them into an empty header set, then adding
those that need to be generated to that new set. Cleanup
reduces to throwing away the generated set.
cheer up!
Roland
Oleg Kalnichevski <ol...@apache.org>
06.11.2003 23:40
Please respond to "Commons HttpClient Project"
To: Jakarata Commons HttpClient mailing list
<co...@jakarta.apache.org>
cc:
Subject: HttpClient Revolutions
Folks,
This is one of those days when my frustration with the existing
HttpClient architecture reaches the point when I can hardly fight off
the idea of stating a fork at SourceForge in order to finally get the
very basic things right. I am really getting tired of patching the
deficient architecture and bending it in all sorts of creative ways.
I was trying to provide a fix for the bug that I introduced with one of
my recent patches (authentication headers created by HttpMethodDirector
end up removed in HttpMethodBase). The nasty thing is that since headers
can be added to the HTTP method in several places, it is not quite clear
at what point auto-generated headers are safe to be removed. If the
auto-generated are cleaned up in the authentication/redirect loop, then
they are not cleaned up in case of automatic recovery from a transport
exception. As a result cookie headers can be duplicated. If the
auto-generated headers are cleaned inside the retry loop, authentication
headers are not re-generated in case of the method retry.
So, once again the real trouble is the ugly design of the HttpMethod
interface/HttpMethodBase class. The decision to recreate request headers
every time the method is being executed was ill-conceived, not to
mention that this is not quite efficient.
I strongly believe that the process of request assembly and request
execution should be decoupled. I suggest the
generateRequstHeaders(HttpState, HttpConnection) method be added to the
HttpMethod interface. The only problem that concerns me is that this may
be too much of a change for 2.1 release, and I once again will end up
accused of all sorts of things ranging from not caring about backward
compatibility to deliberately breaking other people's stuff. Actually
applications that only use public HttpClient APIs will not be affected,
but classes implementing HttpMethod interface will be broken.
Let me know what's your feeling about this
I'm off to bed
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org