Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug #64441 fixed #328

Closed
wants to merge 2 commits into from
Closed

bug #64441 fixed #328

wants to merge 2 commits into from

Conversation

Syra
Copy link
Contributor

@Syra Syra commented Apr 21, 2013

@DaveRandom
Copy link
Contributor

Do you have reference RFC that states this to be valid? An FQDN is not mandated to end with a dot in any URL specifications I can find, and neither does it appear to be legal - the only place that does allow this syntax that I am aware of is the DNS zone files as specified in RFC1035.

I could be wrong, but I suspect that it is parse_url() that is at "fault" here for accepting them, rather than the other way around - although I would say this is not a problem, a parser should be more forgiving than a validator.

@Syra
Copy link
Contributor Author

Syra commented Apr 22, 2013

Yes, it's caused by FQDN. In RFC 1738 "host" is "The fully qualified domain name of a network host".
So valid url may ended by a dot.

@Syra
Copy link
Contributor Author

Syra commented Apr 22, 2013

Updated RFC2396 still the same. RFC3986 supports the same strategy.

@DaveRandom
Copy link
Contributor

After re-reading the relevant RFCs I now agree that this is probably correct behaviour, although it does look a little odd, but since the final empty label refers to the "root domain" this is probably technically valid. It certainly makes sense in terms of how the DNS resolver works.

I will try compiling this later and see if I can break your fix :-P (although at first glance it looks sensible). However, you should definitely add a test to the PR.

@lstrojny
Copy link
Contributor

Yes, please don’t merge without a test.

@Syra
Copy link
Contributor Author

Syra commented Apr 22, 2013

I'm new on this project and I'm glad to get your responses.

@smalyshev
Copy link
Contributor

This passes http://a./ as a correct URL. I don't think it is.

@smalyshev
Copy link
Contributor

Reading RFC, I think I was wrong, trailing dot is valid. But some servers can't handle it properly as it seems: http://stackoverflow.com/questions/3314192/how-do-i-allow-trailing-dot-in-host-headers-in-iis/3483411#3483411
So I'm not sure what to do here...

@lt
Copy link
Contributor

lt commented Jun 17, 2013

@smalyshev We should be server agnostic right? If a particular server has a bug that means it does not conform to the RFC, then the maintainers of that server should fix it.

My personal opinion is that we should allow the trailing dot as a valid hostname, as it is valid per the RFC.

Unrelated but interesting side note, Firefox will complain about hosts with a trailing dot over SSL, because the certificate does not match the hostname. Chrome is happy to accept the host with a trailing dot when the certificate does not match the hostname.

It seems "issues" related to this trailing dot are widespread. Again I think we should comply with the RFC

@dsp
Copy link
Member

dsp commented Sep 16, 2013

I agree we should comply with the RFC, particularly as it's backed by popular DNS software like bind and browsers. I've queued it for 5.4.21 unless there are objections.

@php-pulls
Copy link

Comment on behalf of mike at php.net:

Already merged.

@php-pulls php-pulls closed this Oct 9, 2013
@kaplanlior
Copy link
Contributor

For future reference commit SHA1 is 18b54a2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants