http-access2 help

[Ara.T.Howard]

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
Date: Thu Nov 03 09:33:41 MST 2005
Content-Length: 64
Host: rubyforge.org

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

= Response

HTTP/1.1 302 Found
Date: Thu, 03 Nov 2005 16:24:48 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: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: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
--
===============================================================================
| 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
===============================================================================

 

[Ara.T.Howard]

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

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
--
===============================================================================
| 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
===============================================================================

 

[Alex Fenton]

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 ... but I can't see there would be much harm in http-access2
emulating this widespread 'broken' behaviour - a change request?

alex

 

[Ara.T.Howard]

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.

Neither ... 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
--
===============================================================================
| 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
===============================================================================