Http-access2 help

i'm trying to convert some scripts i have which login in to rubyforge, cache
the login cookie, and allow automatic upload of a new release. they are
working fine attm but they make systems calls to use curl and i'm trying to
port the http-access2 so they might be used on windows too. i'm having an
issue following status 302, as it returned by the login page. here is the
script:

   [ahoward@localhost rubyforge-0.0.0]$ cat login2
   #! /usr/bin/env ruby
   $VERBOSE = nil
   require "getoptlong"
   require "enumerator"
   require "http-access2"
   require "tempfile"

   uri, page = "http://rubyforge.org", "/account/login.php"

   opts =
     GetoptLong::new(
       [ "--username", "-u", GetoptLong::REQUIRED_ARGUMENT ],
       [ "--password", "-p", GetoptLong::REQUIRED_ARGUMENT ],
       [ "--cookie_jar", "-c", GetoptLong::REQUIRED_ARGUMENT ]
     ).enum_for.inject({}){|h,kv| h.update Hash[*kv]}

   username = opts['username'] || ARGV.shift or abort 'no username'
   password = opts['password'] || ARGV.shift or abort 'no password'
   cookie_jar = opts['cookie_jar'] || ARGV.shift || Tempfile::new($0).path

   form = {
     'return_to' => '',
     'form_loginname' => username,
     'form_pw' => password,
     'login' => 'Login'
   }

   client = HTTPAccess2::Client::new ENV['HTTP_PROXY']
   client.set_cookie_store cookie_jar

   response =
     unless ENV['BLOW_UP']
       client.post "#{ uri }/#{ page }", form
     else
       client.debug_dev = STDERR
       client.post_content "#{ uri }/#{ page }", form
     end

   client.save_cookie_store

   p response

   __END__
   <form action="/account/login.php" method="post">
   <input type="hidden" name="return_to" value="" />
   <p>
   Login Name:<br /><input type="text" name="form_loginname" value="" />
   </p>
   <p>
   Password:<br /><input type="password" name="form_pw" />
   </p>
   <p>
   <input type="submit" name="login" value="Login" />
   </p>
   </form>

now, if i run using

   [ahoward@localhost rubyforge-0.0.0]$ ./login2 xxx yyy cookie_jar

   #<HTTP::Message:0xb7e85188 @header=#<HTTP::Message::Headers:0xb7e85250 @request_uri=nil, @header_item=[["Date", "Thu, 03 Nov 2005 16:21:10 GMT"], ["Server", "Apache/1.3.33 (Unix) mod_gzip/1.3.26.1a PHP/4.4.1"], ["Vary", "Accept-Encoding"], ["X-Powered-By", "PHP/4.4.1"], ["Expires", "Wed, 11 Nov 1998 11:11:11 GMT"], ["Cache-Control", "must-revalidate"], ["Set-Cookie", "session_ser=abcxyz; expires=Thursday, 10-Nov-05 16:21:10 GMT; path=/; domain=.rubyforge.org"], ["Location", "/my/"], ["Transfer-Encoding", "chunked"], ["Content-Type", "text/html"]], @body_type=nil, @request_method=nil, @body_date=nil, @request_via_proxy=nil, @http_version="1.1", @reason_phrase="Found\r", @body_size=0, @request_query=nil, @is_request=false, @response_status_code=302, @chunked=false, @body_charset=nil>, @body=#<HTTP::Message::Body:0xb7e850c0 @boundary=nil, @charset=nil, @type=nil, @chunk_size=4096, @body=
"", @date=nil>>

the login works - the cookie is returned. however, the login page is supposed
to bounce you back to http://rubyforge.org/my/, as you can see by the 302
(FOUND) status code and the ["Location", "/my/"] header. i figured i could use
post_content to follow this, at least the source seems to read this way... so
i tried:

   [ahoward@localhost rubyforge-0.0.0]$ BLOW_UP=true ./login2 xxx yyy
   = Request

   ! CONNECT TO rubyforge.org:80
   ! CONNECTION ESTABLISHED
   POST //account/login.php HTTP/1.1
   content-type: application/x-www-form-urlencoded
   Content-Length: 64
   Host: rubyforge.org

   form_pw=yyy&form_loginname=xxx&return_to=&login=Login

   = Response

   HTTP/1.1 302 Found
   Server: Apache/1.3.33 (Unix) mod_gzip/1.3.26.1a PHP/4.4.1
   Vary: Accept-Encoding
   X-Powered-By: PHP/4.4.1
   Expires: Wed, 11 Nov 1998 11:11:11 GMT
   Cache-Control: must-revalidate
   Set-Cookie: session_ser=abcxyz; expires=Thursday, 10-Nov-05 16:24:48 GMT; path=/; domain=.rubyforge.org
   Location: /my/
   Transfer-Encoding: chunked
   Content-Type: text/html

   0

   = Request

   ! CONNECT TO :0
   /usr/local/lib/ruby/site_ruby/1.8/http-access2.rb:1109:in `initialize': Connection refused - connect(2) (, #0) (Errno::ECONNREFUSED)
           from /usr/local/lib/ruby/site_ruby/1.8/http-access2.rb:1109:in `initialize'
           from /usr/local/lib/ruby/site_ruby/1.8/http-access2.rb:76:in `new'
           from /usr/local/lib/ruby/site_ruby/1.8/http-access2.rb:1099:in `create_socket'
           from /usr/local/lib/ruby/site_ruby/1.8/http-access2.rb:1389:in `create_socket'
           from /usr/local/lib/ruby/site_ruby/1.8/http-access2.rb:1352:in `connect'
           from /usr/local/lib/ruby/site_ruby/1.8/http-access2.rb:1351:in `timeout'
           from /usr/local/lib/ruby/1.8/timeout.rb:62:in `timeout'
            ... 7 levels...
           from /usr/local/lib/ruby/site_ruby/1.8/http-access2.rb:245:in `post_content'
           from /usr/local/lib/ruby/site_ruby/1.8/http-access2.rb:244:in `retry_connect'
           from /usr/local/lib/ruby/site_ruby/1.8/http-access2.rb:244:in `post_content'
           from ./login2:36

but no go. it looks like it drops the host on the redirect an tries to connect
to localhost or something...

am i doing something wrong or is this a bug?

kind regards.

-a

···

Date: Thu Nov 03 09:33:41 MST 2005
   Date: Thu, 03 Nov 2005 16:24:48 GMT
--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
anything that contradicts experience and logic should be abandoned.
-- h.h. the 14th dalai lama

===============================================================================

the following code allows my request to succeed:

   client.redirect_uri_callback = lambda do |res|
     page = res.header['location'].first
     uri = "http://rubyforge.org/#\{ page }"
   end

   response = client.get_content "#{ uri }/#{ page }", form

so it does indeed seem that the default redirect_uri_callback callback takes
the location but drops the host... is this my fault or a bug?

regards.

-a

···

On Fri, 4 Nov 2005, Ara.T.Howard wrote:

response =
   unless ENV['BLOW_UP']
     client.post "#{ uri }/#{ page }", form
   else
     client.debug_dev = STDERR
     client.post_content "#{ uri }/#{ page }", form
   end

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
anything that contradicts experience and logic should be abandoned.
-- h.h. the 14th dalai lama

===============================================================================

Hi Ara

the login works - the cookie is returned. however, the login page is supposed
to bounce you back to http://rubyforge.org/my/, as you can see by the 302
(FOUND) status code and the ["Location", "/my/"] header.

I am pretty sure that the HTTP spec requires that a Location header content
is a full, absolute URL including protocol and server. The behaviour
of treating a 'broken' relative URL in a Location header by joining to the server
in the original request is pervasive among user agents, but I think http-access2
is probably entitled not to implement it.

On a really pernickety reading of the HTTP spec, I think 303 is the correct
response for the server to issue in these circumstances (redirecting a
POST to a GET), but I've never seen it "in the wild".

am i doing something wrong or is this a bug?

Neither :slight_smile: ... but I can't see there would be much harm in http-access2
emulating this widespread 'broken' behaviour - a change request?

alex

Hi Ara

the login works - the cookie is returned. however, the login page is supposed
to bounce you back to http://rubyforge.org/my/, as you can see by the 302
(FOUND) status code and the ["Location", "/my/"] header.

I am pretty sure that the HTTP spec requires that a Location header content
is a full, absolute URL including protocol and server. The behaviour of
treating a 'broken' relative URL in a Location header by joining to the
server in the original request is pervasive among user agents, but I think
http-access2 is probably entitled not to implement it.

On a really pernickety reading of the HTTP spec, I think 303 is the correct
response for the server to issue in these circumstances (redirecting a POST
to a GET), but I've never seen it "in the wild".

hmmm. i'm reading

   http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
   http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30

you seem to be right.

am i doing something wrong or is this a bug?

Neither :slight_smile: ... but I can't see there would be much harm in http-access2
emulating this widespread 'broken' behaviour - a change request?

this seems reasonable - after all - the entire reason one uses http-access2
instead of the net/http is to avoid needing to consider precisely these kinds
of issues.

regards.

-a

···

On Fri, 4 Nov 2005, Alex Fenton wrote:
--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
anything that contradicts experience and logic should be abandoned.
-- h.h. the 14th dalai lama

===============================================================================

Hi,

Sorry for late reply again. It needed half a year to fix.

Ara.T.Howard wrote:

am i doing something wrong or is this a bug?

Neither :slight_smile: ... but I can't see there would be much harm in http-access2
emulating this widespread 'broken' behaviour - a change request?

this seems reasonable - after all - the entire reason one uses http-access2
instead of the net/http is to avoid needing to consider precisely these
kinds
of issues.

I finally decided to implement that 'broken' behavior (with warning).
Can someone try preview release of version 2.0.7? I want to make sure
that this release correctly implemented the behavior.
http://dev.ctor.org/download/http-access-20060717.tar.gz

Regards,
// NaHi