Lynx 2.8.7 and numeric IPv6 adddresses

[Andre-John Mas]

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

[Thomas Dickey]

Post by Andre-John Mas
Hi,
I have just installed lynx 2.8.7dev.7 on my Mac, specifying the IPv6
./configure --enable-ipv6 --prefix=/usr/local/lynx
lynx "http://127.0.0.1/"
lynx "http://[::1]/"
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 ;-)

[Andre-John Mas]

Post by Thomas Dickey

Post by Andre-John Mas
Hi,
I have just installed lynx 2.8.7dev.7 on my Mac, specifying the IPv6
./configure --enable-ipv6 --prefix=/usr/local/lynx
lynx "http://127.0.0.1/"
lynx "http://[::1]/"
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

[Thomas Dickey]

Post by Andre-John Mas

Post by Thomas Dickey
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...

[Andre-John Mas]

Post by Thomas Dickey

Post by Andre-John Mas

Post by Thomas Dickey
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

[Thomas Dickey]

Post by Andre-John Mas

Post by Thomas Dickey
advice). But HTParse.c is the starting point.

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

Post by Andre-John Mas
- 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.

[Andre-John Mas]

Post by Thomas Dickey

Post by Andre-John Mas

Post by Thomas Dickey
advice). But HTParse.c is the starting point.

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

Post by Andre-John Mas
- 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
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

[Thomas Dickey]

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.

[h***@tbbs.net]

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.)

[Thomas Dickey]

Post by Thomas Dickey

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
<<<<<<<<
node::device:<level.level>filename.suffix;1 ....

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

Post by Thomas Dickey
--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: "*"

[h***@tbbs.net]

20080108 09:35 -0500, Thomas Dickey >>>>

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: "*"
<<<<<<<<
Double-quotes are also used for filenames on external devices wheron it is
not guaranteed that the VMS naming rules are followed, eg, on magnetic tape.
Maibe this is irrelevant to Lynx.

In the directory path there is also the trailind wildcard "..." which stands
for the directory s descendants, too, and the leadind character "-." which
is like "../" in Unix.

Maibe it is time for a VMS reference, ....

[Andre-John Mas]

Hi,

Its been a while since I have touched C, though this is a state machine that I developped a few years ago that does the job for URIs:

http://ajmas.dyndns.org/misc/uriparser.c.txt

I generally consider it to be up for grabs and open for improvement. I'll see how this melds with lynx later in the week, since I don't have too much time at the moment. There may even be a way of applying a simpler modification.

A quick test shows that VMS pass, but the '/' would need to be removed fromt the path.

BTW how stringent should the parser be, with regards to malformed URL?

Andre

[Thomas Dickey]

Post by Andre-John Mas
Hi,
http://ajmas.dyndns.org/misc/uriparser.c.txt
I generally consider it to be up for grabs and open for improvement. I'll see how this melds with lynx later in the week, since I don't have too much time at the moment. There may even be a way of applying a simpler modification.
A quick test shows that VMS pass, but the '/' would need to be removed fromt the path.
BTW how stringent should the parser be, with regards to malformed URL?

I suppose it depends on what type of malformation...

[Thorsten Glaser]

Post by Andre-John Mas
lynx "http://[::1]/"

FWIW, the SSL validation code can handle
https://[x:y::z]:444/

I already thought of that, so that you don't need to touch it.

//mirabilos