Sounds good. Thanks.
-Matthew Ring -----Original Message----- From: Ross Rankin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 18, 2003 1:26 PM To: 'Commons HttpClient Project' Subject: RE: redirects not allowed for PostMethod Just as a FYI, as a workaround I would get the header on any request that was 301, 302 or 307. The header looks like this: HTTP/1.1 302 Object Moved Location: http://www.mysite.com/home1.cfm?CFID=5469622&CFTOKEN=17732201 Server: Microsoft-IIS/5.0 Content-Type: text/html Content-Length: 201 I would pull Location and place the value into get.setPath and get that page. It seems to work well for me and works a number of sites I have tested. Ross -----Original Message----- From: Couball, James [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 18, 2003 2:11 PM To: 'Commons HttpClient Project' Subject: RE: redirects not allowed for PostMethod 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] > 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: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
