Lynx 2.8.7 and numeric IPv6 adddresses

Hi,

I have just installed lynx 2.8.7dev.7 on my Mac, specifying
the IPv6
option for the configuration:

  ./configure --enable-ipv6 --prefix=/usr/local/lynx

Everything builds and installs. I am able to connect to:

  lynx "http://127.0.0.1/"

But if I specify the valid IPv6 URL, which works with
Safari:

  lynx "http://[::1]/"

I get the error:

  Alert!: Unable to connect to remote host.

  lynx: Can't access startfile http://[/

This would like a URL parsing issue. Can anyone confirm the
problem?

Andre


_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

On Mon, 7 Jan 2008, Andre-John Mas wrote:

> Hi,
>
> I have just installed lynx 2.8.7dev.7 on my Mac,
specifying the IPv6
> option for the configuration:
>
>  ./configure --enable-ipv6 --prefix=/usr/local/lynx
>
> Everything builds and installs. I am able to connect
to:
>
>  lynx "http://127.0.0.1/"
>
> But if I specify the valid IPv6 URL, which works with
Safari:
>
>  lynx "http://[::1]/"
>
> I get the error:
>
>  Alert!: Unable to connect to remote host.
>
>  lynx: Can't access startfile http://[/
>
> This would like a URL parsing issue. Can anyone confirm
the problem?

lynx supports IPv6 internally - should be able to connect to
a host using 
DNS or a properly constructed hosts file, but doesn't
implement the 
literals.

(This is known - patches welcome 

-- 
Thomas E. Dickey
http://invisible-island.n
et
ftp://invisible-island.net


_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

On 7-Jan-08, at 18:04 , Thomas Dickey wrote:

> On Mon, 7 Jan 2008, Andre-John Mas wrote:
>
>> Hi,
>>
>> I have just installed lynx 2.8.7dev.7 on my Mac,
specifying the IPv6
>> option for the configuration:
>>
>> ./configure --enable-ipv6 --prefix=/usr/local/lynx
>>
>> Everything builds and installs. I am able to
connect to:
>>
>> lynx "http://127.0.0.1/"
>>
>> But if I specify the valid IPv6 URL, which works
with Safari:
>>
>> lynx "http://[::1]/"
>>
>> I get the error:
>>
>> Alert!: Unable to connect to remote host.
>>
>> lynx: Can't access startfile http://[/
>>
>> This would like a URL parsing issue. Can anyone
confirm the problem?
>
> lynx supports IPv6 internally - should be able to
connect to a host  
> using DNS or a properly constructed hosts file, but
doesn't  
> implement the literals.
>
> (This is known - patches welcome 
>

Just to give me a head start, which file is responsible for
the parsing?

Andre



_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

On Mon, 7 Jan 2008, Andre-John Mas wrote:

>> lynx supports IPv6 internally - should be able to
connect to a host using 
>> DNS or a properly constructed hosts file, but
doesn't implement the 
>> literals.
>> 
>> (This is known - patches welcome 
>> 
>
> Just to give me a head start, which file is responsible
for the parsing?

The largest chunk is in

 	WWW/Library/Implementation/HTParse.c

though there'll be scattered fixes - the square brackets for
instance 
could collide with the VMS pathname parsing (I'm not sure -
just general
advice).  But HTParse.c is the starting point.

I've mostly been working on vile and xterm the past few
months, have been
working on lynx's backlog the past week or so...

-- 
Thomas E. Dickey
http://invisible-island.n
et
ftp://invisible-island.net


_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

On 7-Jan-08, at 20:18 , Thomas Dickey wrote:

> On Mon, 7 Jan 2008, Andre-John Mas wrote:
>
>>> lynx supports IPv6 internally - should be able
to connect to a  
>>> host using DNS or a properly constructed hosts
file, but doesn't  
>>> implement the literals.
>>> (This is known - patches welcome 
>>
>> Just to give me a head start, which file is
responsible for the  
>> parsing?
>
> The largest chunk is in
>
> 	WWW/Library/Implementation/HTParse.c
>
> though there'll be scattered fixes - the square
brackets for  
> instance could collide with the VMS pathname parsing
(I'm not sure -  
> just general
> advice).  But HTParse.c is the starting point.

Thanks I'll take a look at that. A few questions:
  - Are there any VMS implementations that support IPv6?
  - Are there any good references describing the syntax of
VMS path?

Andre


_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

On Mon, 7 Jan 2008, Andre-John Mas wrote:

>> advice).  But HTParse.c is the starting point.
>
> Thanks I'll take a look at that. A few questions:
> - Are there any VMS implementations that support IPv6?

google "vms ipv6" indicates that it's supported.

This side of it is probably not a big concern - VMS users
are few...

> - Are there any good references describing the syntax
of VMS path?

There are manuals on HP's site (I'm not that familiar with
where to
find them).  Essentially a VMS pathname could look like
this:

 	node::device:[level.level]filename.suffix;1

The parts are optional, e.g.,

 	[level.level]	is a valid directory name
 	[000000]	is like the "/" path on Unix
 	[level.]	is valid too

I've cleaned up most of the checks for string-as-url versus

string-as-pathname, but adding square brackets to the URLs
runs the risk 
of tripping over some check for VMS.

Of course "usually" a pathname is distinct from
URL, and most of the
VMS code is ifdef'd.

-- 
Thomas E. Dickey
http://invisible-island.n
et
ftp://invisible-island.net


_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

On 7-Jan-08, at 20:37 , Thomas Dickey wrote:

> On Mon, 7 Jan 2008, Andre-John Mas wrote:
>
>>> advice).  But HTParse.c is the starting point.
>>
>> Thanks I'll take a look at that. A few questions:
>> - Are there any VMS implementations that support
IPv6?
>
> google "vms ipv6" indicates that it's
supported.
>
> This side of it is probably not a big concern - VMS
users are few...
>
>> - Are there any good references describing the
syntax of VMS path?
>
> There are manuals on HP's site (I'm not that familiar
with where to
> find them).  Essentially a VMS pathname could look like
this:
>
> 	node::device:[level.level]filename.suffix;1
>
> The parts are optional, e.g.,
>
> 	[level.level]	is a valid directory name
> 	[000000]	is like the "/" path on Unix
> 	[level.]	is valid too
>
> I've cleaned up most of the checks for string-as-url
versus string- 
> as-pathname, but adding square brackets to the URLs
runs the risk of  
> tripping over some check for VMS.
>
> Of course "usually" a pathname is distinct
from URL, and most of the
> VMS code is ifdef'd.

So in this case, we could technically not provide ipv6
support for  
VMS, if it makes it easier adding proper support for other
platforms?  
I tempted to try supporting most platforms and then coming
back and  
seeing what can be done for VMS.

Andre


_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

On Mon, 7 Jan 2008, Andre-John Mas wrote:

> So in this case, we could technically not provide ipv6
support for VMS, if it 
> makes it easier adding proper support for other
platforms? I tempted to try 
> supporting most platforms and then coming back and
seeing what can be done 
> for VMS.

yes - bearing in mind that support for IPv6 is already
ifdef'd, it would
make sense to ifdef the parsing changes to match that.

-- 
Thomas E. Dickey
http://invisible-island.n
et
ftp://invisible-island.net


_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

>>>> 20080107 20:37 -0500, Thomas Dickey
>>>>
	node::device:[level.level]filename.suffix;1

The parts are optional, e.g.,

	[level.level]	is a valid directory name
	[000000]	is like the "/" path on Unix
	[level.]	is valid too 
<<<<<<<<
And the use of angle-brackets is also valid:
	node::device:<level.level>filename.suffix;1 ....
--just to complicate things, ... from TOPS-10 & -20, I
suspect ... and
double-quotes and wild-cards also have a place. (When I used
VMS I always
preferred the angle-brackets.)



_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

On Tue, 8 Jan 2008, hsvtbbs.net wrote:

>>>>> 20080107 20:37 -0500, Thomas Dickey
>>>>
> 	node::device:[level.level]filename.suffix;1
>
> The parts are optional, e.g.,
>
> 	[level.level]	is a valid directory name
> 	[000000]	is like the "/" path on Unix
> 	[level.]	is valid too
> <<<<<<<<
> And the use of angle-brackets is also valid:
> 	node::device:<level.level>filename.suffix;1
....

yes - and the semicolon can be a different character also
(iirc, a ".").

> --just to complicate things, ... from TOPS-10 &
-20, I suspect ... and
> double-quotes and wild-cards also have a place. (When I
used VMS I always
> preferred the angle-brackets.)

double-quotes can appear in a node-name (something like that
- I've seen
it documented but don't recall the exact terminology up at
the node 
level).

wildcards at least are comparable to other systems:
"*"

-- 
Thomas E. Dickey
http://invisible-island.n
et
ftp://invisible-island.net


_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev