Topic: Problem with IPv6 HTTP request with SCOPEID on Apache-2.2.11

[sathya]

Hi Apache developers,

I could sucessfully compile Apache-2.2.11 with IPv6 support being enabled and could confirm it with "netstat -an | grep tcp6" to see if httpd is running at port 80 for IPv6 address as well.

But when I type URL something like http://[fe80::2e0:81ff:fe78:cd12%4]/ on my Firefox browser (IE7 doesn't allow this URL at all) with the SCOPE-ID in the URL, apache is giving the following error message when the HTTP request has IPv6 scope-id in "Host:" field ("Host:fe80::2e0:81ff:fe78:cd12%4"),

"HTTP/1.1 400 Bad Request
...
Your browser sent a request that this server could not understand."

I could see that there is already a [Bug 35122] raised on Apache-2.x for scope-if support but looks like even in apache-2.2.11, this doesn't seems to be fixed.

Could you please help me out with the following clarifications on this,

1. Is it a valid behavior for Apache to now allow any request if the HTTP request has IPv6 scope-id in "Host:" field ?
-> If yes, could you please let me know on how can I work around this.
-> If this is defect with apache, could you please let me know on can we fix this issue.

Could you please let me know your thoughts on this.

Thanks and regards,
Sathya


Could you please let me know your views on this by earliest.

Thanks and regards,
Sathya

[glsmith]

http://[fe80::2e0:81ff:fe78:cd12] <- no %4$

[sathya]

-> I had even tried it..When I type http://[fe80::2e0:81ff:fe78:cd12] on my browser (IE7 and mozilla), its giving me that URL not found.

-> But, when I do "telnet fe80::2e0:81ff:fe78:cd12%4 80" from command prompt, I am able to connect to HTTP server as expected.

-> I even tried typing http://[fe80::2e0:81ff:fe78:cd12%254] on my browser with an intention to escape "%" symbol on URI. But still no success.

Could you please let me know on how can I actually use this feature.

[glsmith]

I doubt I can since I have not yet wrapped my head around IPv6, but when I tested IPv6 on my XP box, I quickly found that the %what-have-you on the end did not work. Without it however it did work in Firefox .. nothing worked in IE.

http://www.justmyspace.org/ap2212v6NT51.png

build however does include https://issues.apache.org/bugzilla/show_bug.cgi?id=45321
whether this matters on anything other XP I cannot say, curious as to what Windows you are running.

[glsmith]

upon a little googling since I didn't know what the scope-id was, I did find this at msdn

[sathya]

Thanks for your quick response.

I am running apache-2.2.11 on Debian Linux with the IPv6 fix being included.

The "ifconfig" command on Linux gave me "inet6 addr: fe80::2e0:81ff:fe81:1124/64 Scope:Link" IPv6 information.

Then from windows XP system, I could succesfully ping & telnet to port 80 (http port) on fe80::2e0:81ff:fe81:1124%4 address. And could see the apache's response for "telnet fe80::2e0:81ff:fe81:1124 80" in access.log and error.log if I type a wrong command.

But, irrespective of when I type http://[fe80::2e0:81ff:fe81:1124%4] (or) http://[fe80::2e0:81ff:fe81:1124%254] (or) http://[fe80::2e0:81ff:fe81:1124] in Internet explorer 7 and mozilla firefox 3.0.10, its not working as expected.

In case http://[fe80::2e0:81ff:fe81:1124%4] , apache is responding with "400 Bad request" And in the case of http://[fe80::2e0:81ff:fe81:1124] , mozilla reports that it can't establish connection with [fe80::2e0:81ff:fe81:1124].


Could you please let me know your thoughts on this.

[glsmith]

Other than I see the different syntax for the scope id between Debian and XP, and that IPv6 is not ready for prime time regardless of system/OS ... no, I wish I could.

Also, I just threw it on another box and gave it a try over the LAN and boom ... works with the %scope id but not without. However, works just means Apache answers .. but I get the bad request error.

I need to play a little more over the lan, see what Apache is seeing when it gives that error, then I may have some clue (yeah right). I'll get back to you on that.

Do you have more than one *nix box on the LAN? Specifically to check across from one computer to the other with that Linux syntax. I have a fedora 10 box but it's a real pecker (lots of things do not work proper) and I have 11 more days till Fedora 11.

I really want to bring up the patch to the list, and getting this mess tested across the *nix/Windows platforms would be helpful in pushing it forward. There is obviously a need to get the syntax for this scope ID in the RFC ... or it's never going to work period.

We have 2 years to get this mess figured out, so said Iana, or Arin a couple weeks ago which is what got me messing with it in the first place.

[glsmith]

I cannot seem to trap the error ... there's an error document set for the 400 but it ignores it and gives me the standard run of the mill built in error page. Makes this mess even more difficult.

[James Blond]

4xx errors are client errors. Not the server itself.

Often there is a DNS issue while resolving the server name.

I know that apache don't log that error in the error_log but there should be a line in the access_log.

Not easy with telnet cause you can't see what you typ in, but you can make a request with it.

[glsmith]

Telnet ... what's telnet?
I haven't telnet-ed into anything in at least 7 years.

[glsmith]

Well, I can get across the lan, so where does the DNS part come in?
I think some of the mess is the lack of definition on the id in the RFC.
And here is the error

[Fri May 15 12:47:16 2009] [error] [client fe80::240:f4ff:febc:1489] Client sent malformed Host header

and the access log is even less helpful
fe80::2e0:4dff:fe81:c593 - - [15/May/2009:12:46:01 -0700] "GET / HTTP/1.1" 400 226

For all I know, Apache would work fine from *nix to *nix since Windows, tho not forgotten, is not of most's concern and the two do have a different syntax in use.

As I see it, if Apache just ignored the scope id things would work ... or at least it would not flag the %what-have-you as an error. Or accept both style syntax and work .. either way. But that begs the question, how many other scope id syntaxes are out there with all the different platforms Apache runs on?

As such, everything inside the brackets should be treated as an IP address. And since it works fine locally w/o the scope id, I think appache should just understand that regardless of the what's tacked onto the end, the IP itself is nothing more than 0-9,A-F,a-f, and colons, so anything other than that (and we know it should show up at the end), should be regexed off the request. No? Anything strange not at the end and regexed off should then be treated as a 400.

[sathya]

Hi,

So, do you mean that this is a bug with present version of Apache. If yes, could you please let me know on how do we proceed on this....Please do let me know if you feel that I am missing anything on this.

Thanks and regards,
Sathya

[glsmith]

It's hard to call it a bug when I have no clue how it works between two *nix boxes. If everything works wonderfully there, then yes, I would say it is a bug with Apache when dealing with Windows and MS's take on the scope ID .. then again, can it be a bug in Firefox/Mozilla? What other browsers handle ipv6 that can be tested with?

And there in lies another problem besides the black hole in the RFC, bottom line at this point in time is, it is low hanging fruit.

Like TLS Server Name Indication, it can be done, but up until recently there was no browser support for it, so why spend the time coding it into Apache. When you imagine that the most used browser on the internet is going to be some version of Internet Exploder on WinXP, currently, no IE on XP supports SNI. No Chrome or Safari on XP until that recently changed I think I heard about one of them. With Vista supporting it on the common browsers, there in became the push to get it done.

We're in the same boat here I think and I doubt much is going to get it fixed soon. The patch however is a little different story. If Apache is built with IPv6 support, and Windows XP has IPv6, Apache will crash. The patch cures that and as a side effect allows us to use IPv6 in XP, but only locally obviously because of our other problem, this scope id/bad request business.

I'm not unwilling to go on the mail list and bring this up, but I do not want to sound like a idiot when I finally do. I've done that enough

I guess I'll image a drive and temporarily put Ubuntu on a computer so I can play between the then two Linux boxes. I've got a Vista machine as well to start playing with. If you'd like, E me (ipv6 at justmyspace org) and I'll reply with a real address.

[glsmith]

OK, so here's the end of this thread after a bit of back and forth off the forum.

Apache has no problem with the Scope ID, it is parsed out of the URI when run through apr_parse_addr_port() which then returns the individual pieces of the URI in their respective variables of host, scope id, port, etc. At this point Apache is happy and has no problem.

Apache however plays RFC Police by then denying any request where the scope ID ends up in the host header (and it shouldn't be in there as far as I can tell). So even though this has no effect on Apache, that Apache is policing the RFC becomes the main problem by checking for the scope id then firing a "not supported" bullet back.

The only browser I have really to test all this on is Firefox, and Firefox incorrectly tacks that scope id in the host header. Someone has claimed it's been fixed (In Trunk) 2008-12-06. However, there is a later comment that "This fix is not in the scope of our maintenance releases." So what does that mean? We wait till 3.1 or whatever the next release of Firefox is before this get's fixed in Firefox.

I understand the need for Apache to enforce RFCs on itself, but I do not see the need to then carry a big stick and whack a browser that behaves incorrectly in this situation. I've read RFCs and some take a conference of Quantum Physicists to decipher so misinterpretations of an RFC do not seem so far fetched. In this particular case it's petty, just ignore the scope id and all would be fine, and it is a simple fix, strike that, temporary workaround while browsers adjust to IPv6.