From: Andrew Beers <beers@...>
Date: 2007-08-29T23:33:37+09:00
Subject: Bug in URI.parse?

------_=_NextPart_001_01C7EA49.955C7227
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have looked through the archives for the mailing list, but didn't see
this issue addressed.  So here goes.

=20

My local machine is named 3beers-wrk.  I achieved this by putting an
entry in my local hosts file (since I'm on Windows, this would be in
\windows\system32\drivers\etc\hosts).  However, I have also seen the
issue below reproduce with a machine whose name is similar, say
12345-server.

=20

Below is a capture of my session with the shell, then with irb:

=20

H:\>ping 3beers-wrk

=20

Pinging 3beers-wrk [127.0.0.1] with 32 bytes of data:

=20

Reply from 127.0.0.1: bytes=3D32 time<1ms TTL=3D128

Reply from 127.0.0.1: bytes=3D32 time<1ms TTL=3D128

...

=20

H:\>irb

=20

irb(main):001:0> require 'uri'

=3D> true

=20

irb(main):002:0> URI.parse("http://3beers-wrk.tsi.lan")

=3D> #<URI::HTTP:0x1612dc0 URL:http://3beers-wrk.tsi.lan>

=20

irb(main):003:0> URI.parse("http://3beers-wrk")

URI::InvalidURIError: the scheme http does not accept registry part:
3beers-wrk (or bad hostname?)

        from
c:/p4/workgroup-1.0/workgroup-support/ruby/lib/ruby/1.8/uri/generic.rb:1
94:in `initialize'

        from
c:/p4/workgroup-1.0/workgroup-support/ruby/lib/ruby/1.8/uri/http.rb:46:i
n `initialize'

        from
c:/p4/workgroup-1.0/workgroup-support/ruby/lib/ruby/1.8/uri/common.rb:48
4:in `new'

        from
c:/p4/workgroup-1.0/workgroup-support/ruby/lib/ruby/1.8/uri/common.rb:48
4:in `parse'

        from (irb):3

        from
c:/p4/workgroup-1.0/workgroup-support/ruby/lib/ruby/1.8/uri/http.rb:57

=20

URI.parse() is not properly parsing the non-qualified name 3beers-wrk
(though it does properly parse a fully-qualified hostname), which seems
to be in line with the grammar set forth in RFC2396.  However, the RFC
makes the following comment:  "In practice, however, the host component
may be a local domain literal" (section 3.2).  This suggests that the
above URI is entirely valid.  Further, this URI is acceptable to Web
browsers.

=20

Is this a bug?  How can I handle this seemingly valid URI?

=20

Thanks!

Andrew


------_=_NextPart_001_01C7EA49.955C7227--