hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <o.kalnichev...@dplanet.ch>
Subject RE: redirects not allowed for PostMethod
Date Tue, 18 Mar 2003 19:06:26 GMT
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
> 


Mime
View raw message