Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Message-ID: <718DA1709308D311A6750008C70954E301DD2DC4@SCAL10>
From: "Couball, James" <James.Couball@cotelligent.com>
To: "'Commons HttpClient Project'"
	 <commons-httpclient-dev@jakarta.apache.org>
Subject: RE: redirects not allowed for PostMethod
Date: Tue, 18 Mar 2003 14:11:06 -0500
MIME-Version: 1.0
Content-Type: text/plain

Oleg,

Yes, I read some of the other posts after responding and saw that there is
the difficultly you mention.  

My usage of the HTTPClient wraps the submit functionality to provide
redirect functionality and returns the method object as you would an
HTTPResponse.  What I have done isn't good enough for posting, but worked
for what I was doing.

Sincerely,
James.


-----Original Message-----
From: Oleg Kalnichevski [mailto:o.kalnichevski@dplanet.ch] 
Sent: Tuesday, March 18, 2003 11:06 AM
To: Commons HttpClient Project
Subject: RE: redirects not allowed for PostMethod

James,

I can't say I disagree. By no means we want to turn into RFC Ayatollahs
here.

This said, the real problem is that due to some deficiencies in the
current architecture, it is just not possible to change the type of the
method being executed. Plain silly. But that's the way it is. We are
aware of this problem and would like to fix it. I (currently) see only
one feasible approach toward solving it: split HttpMethod into
HttpRequest/HttpResponse pair. However, that would mean too much of a
change we, as a team, are prepared to live with at the moment.

I suggest that you file a bug (feature request) report for the time
being. As soon as we have 2.0 release behind us, we'll definitely
revisit this issue

I apologize for being unable to do more for you right now 

Oleg

On Tue, 2003-03-18 at 18:56, Couball, James wrote:
> Oleg,
> 
> The defacto standard is that redirects are allowed after a POST and those
> redirects are submitted from the client agent as a GET request -- despite
> with the RFC states.  Every browser I have tested against behaves this
way.
> 
> 
> Your previous statement:
> 
> "a well-behaving browser should provide the end user with a confirmation
> dialog or a configuration option to automatically perform POST redirects" 
> 
> follows the letter of the RFC, but does not reflect what happens in the
real
> world.  In fact, I am not aware of a browser that has this behavior.
> 
> In addition, following a POST with a redirect is a prevalent design
pattern
> to avoid problems when the user hits reload after posting a form.  The
> problem is that most APIs don't distinguish between 301, 303, or 307
> redirects.  Of the APIs I have used, all treat redirect as simply a 301
> response.
> 
> If browsers actually followed the this part of the RFC, _many_ websites
> would be unusable.
> 
> What is the vision of this project?  RFC or real world?  My viewpoint is
> that the RFC is a great guideline, but in some instances (such as this
one)
> does not reflect reality of how this library will be used.
> 
> My suggestion (FWIW) is to allow redirects after a POST (submitted as a
GET)
> as default behavior.  The RFC compliant behavior should be an option...
one
> that I don't see the use case for.
> 
> Sincerely,
> James.
> 
> 
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:o.kalnichevski@dplanet.ch] 
> Sent: Monday, March 17, 2003 3:01 PM
> To: Commons HttpClient Project
> Subject: Re: redirects not allowed for PostMethod
> 
> Hi Matthew
> 
> We have had quite a bit of argument regarding automatic POST redirects a
> while ago
> 
>
http://www.mail-archive.com/commons-httpclient-dev%40jakarta.apache.org/msg0
> 1116.html
> 
> If you disagree with the conclusion we arrived at, feel free to file a
> bug report. We would not mind providing this option in the future. I
> just personally think it's unreasonable, but, again, there are ways of
> seeing and not seeing
> 
> Cheers
> 
> Oleg
> 
> 
> On Mon, 2003-03-17 at 23:51, Matthew S. Ring wrote:
> > Hi,
> > 
> > I just started using the latest version of the HTTPClient to
screen-scrape
> > from Rational Clear Quest. Unfortunately, CQ expects POSTed requests and
> > responds with a redirect. IE and Mozilla-based browsers seem OK with
that,
> > but the HTTPClient refuses to follow redirects after a POST, due to
stated
> > conflicts with RFC 2616. Is this stringency really neccesary? Selfishly,
> it
> > would be nice if I could just turn off this bit of compliance checking
> with
> > a boolean flag. Opinions?
> > 
> > Thanks.
> > 
> > -Matthew Ring
> > 
> > 
> > ---------------------------------------------------------------------
> > 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
> 
> ---------------------------------------------------------------------
> 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