no objection, as discussed in the redhat bug that seems to be a valid delim where you could do "foo bar baz" and then x[0], x[4], x[8] without terminating, but I can't think of any reason we would want to allow that in the hostname. i'll watch his presentation this week so i can get more detail

Shouldn't we rather fail already in url.c:parseurlandfillconn() if there's a space in the host name?

I will maintain and emphasize that curl still doesn't do a 100% validity check on the URL so the fact that curl considers a URL to be slightly different than other URL parsers when given crap is not surprising. I will also maintain that this is also a direct result of the fact that the URL spec situation right now is mostly anarchy and decay. It is hard to know how to parse "URLs".

That's related but somewhat separate. Essentially the parser is a little forgiving to be compatible with the wackiness out there, but I can't think of any broken implementation writing a Location like
http://foo bar/baz
I'm sure you would agree that just doesn't make any sense.

I do indeed think we should reject spaces in host names. My comment about not checking 100% correctness was more in regards to the general problem discussed in the presentation by Orange.

"foo bar baz"

getaddrinfo() only accepts names containing whitespace if the first element is a numerical IP address. The reason is that some getaddrinfo() implementations call inet_aton(). The input for inet_aton() may be "zero-terminated" or "whitespace-terminated". See inet_addr.c (glibc)

Shouldn't we rather fail already in url.c:parseurlandfillconn() if there's a space in the host name?

Makes sense, because there are some other URL syntax checks in this function.

On the other hand, it's probably easier to let getaddrinfo() check the syntax of the hostname. The rules for valid hostnames may be complex.

On the other hand, it's probably easier to let getaddrinfo() check the syntax of the hostname. The rules for valid hostnames may be complex.

Right, a check in url.c:parseurlandfillconn() could check for valid URL letters, and space is not one...

Is the NetBSD behavior wrong? If so, I will report it as a bug.

@krytarowski I have no doubts that the libc hackers will have their entirely own and unique perspective on whether this is the correct behavior or not... ask them!

@krytarowski yes, please file a bug report for NetBSD. While you are at it, could you also file a bug report for FreeBSD...? They probably use the same code anyway and could share the bugfix.

yes, please file a bug report for NetBSD.

OK, thanks!

could you also file a bug report for FreeBSD...?

No.

Hmm.. I was trying to find a reproducer in C that behaves differently on NetBSD/FreeBSD/Linux vs OpenBSD. I don't observe a different behavior.

Could you please show an example code to show the problem.

Could you please show an example code to show the problem.

Example code: getaddrinfotest.c

I have an access to a remote OpenBSD host with 6.1.

$ ./a.out                                                                                                                            
127.0.0.1
$ uname -a
OpenBSD obsd 6.1 GENERIC#19 i386

My desktop:

rugged$ ./a.out  
127.0.0.1
rugged$ uname -a
NetBSD rugged 8.99.1 NetBSD 8.99.1 (GENERIC) #7: Mon Jul  3 15:56:30 CEST 2017  root@chieftec:/public/netbsd-root/sys/arch/amd64/compile/GENERIC amd64

The result is the same.

In my tests, OpenBSD has sent a query to the DNS server to resolve 127.0.0.1 www.example.com. So the result depends on the DNS server that the system uses, but OpenBSD is not (directly) affected by the bug. I have tested with Google's DNS server (8.8.8.8) in /etc/resolv.conf.

My test results (OpenBSD run inside a VMware VM):

$ uname -a
OpenBSD openbsd.localdomain 6.2 GENERIC#163 i386
$ ./a.out
getaddrinfo: no address associated with name

$ uname -a
OpenBSD openbsd.localdomain 6.1 GENERIC#291 i386
$ ./a.out
getaddrinfo: no address associated with name

$ uname -a
OpenBSD openbsd.localdomain 6.0 GENERIC#1917 i386
$ ./a.out
getaddrinfo: no address associated with name

So, is there a better test-case regardless of DNS server?

So, is there a better test-case regardless of DNS server?

I don't know. I don't mind reporting the bug myself with the testcase at hand.

Someone (TCP/IP stack engineer) suggested me that OpenBSD is wrong and NetBSD is behaving correctly. This behavior depending on DNS is suspicious.

I have reported the bug in getaddrinfo() to FreeBSD and NetBSD.