666542 - In Firefox versions from 4 links provided by a reverse ftp proxy has the auth part in it and can't be clicked.

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Janne]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110613 SUSE/3.6.18-2.1 Firefox/3.6.18
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110613 SUSE/3.6.18-2.1 Firefox/3.6.18

When using Firefox version 4.0.1 or version 5.0-3 on openSuSE 11.4 there is a difference in how some URL's are resolved compared to Firefox version 3.*
(the one I've compared to here is version 3.6.18).

I have an apache 2.2 server on a Linux host (host1) which act as a reverse proxy
server for a FTP photo archive on an IIS server (host2).

This is setup with apache's reverse proxy commands on host1 like this:
(Host names and domain is fake for security reasons)
---------------------
ProxyPass /photos/ ftp://host2.domain.net/photo/
ProxyPassReverse /photos/ ftp://host2.domain.net/photo/
---------------------

It is then accessed like this:

http://host1.domain.net/photos/

The IIS FTP server (host2) will then popup an authorization dialog where we in this case login with username "user" and a password.

Then the user can click on directories to get there and download/display
pictures.

That's how it worked with Firefox 3.*.

Now with Firefox 4 or 5 user can't click the directory because when hovering the
mouse over the link the URL is different than it is with Firefox 3.*.

With Firefox 3.* the link works and lookes like this:

http://host1.domain.net/photos/directory/

With Firefox 4.* or 5.* the link doesn't work and look like this:

http://host1.domain.net/photos/user@photos/directory/

and the target can of course not be found !

So with Firefox 4.* or 5.* the authorization part is added to the URL.

Funny thing is that when rightclicking on the page and viewing page source,
the links/direcories can be clicked as before from there !

I don' know if this is a bug or a feature.
I've tried with a new profile and with different users.

My question is:

Is there a way in Firefox 4.* - 5.* to change that behavior back to as it where ?

Reproducible: Always

Steps to Reproduce:
1.Install an apache server 2.2 with proxy commands as described above.

2. Install an IIS FTP server that's not available for "anonymous" use.

3. Go to the location: http://host1.domain.net/photos/login with username
and a password and try to click a link.



Actual Results:  
Link/Directory is not found.

Expected Results:  
Link/Directory found.

If it's a bug, then the auth part shouldn't be in the url.

Comment 1

[Janne]

Point 3. in the "Reproducible" should say:

3. Go to the location: http://host1.domain.net/photos/
login with username and a password and try to click a link.

Comment 2

[Matthias Versen [:Matti]]

>Is there a way in Firefox 4.* - 5.* to change that behavior back to as it where ?
A bug can be fixed but it's unknown if this is a real bug. There is not enough information in this report.

from the Firefox side you are doing this (right?):
1) open http://host1.domain.net/photos/login
2) the server sends a http 401 response or do you get a page with a username/password form  ?
3) Firefox either sends the basic authentication header or a form post depending on 3
4) the server sends a html file

Either there is a difference with the sent data from 3) or the html gets parsed differently.
You can only find a difference in 3) with a packet trace or gecko http log and a difference in parsing the html can not be found without the html that the server sends.

Can you open about:config and change html5.parser.enable to false and try it again ?
Please don't forget to change it back because it will break other pages.
Does it make a difference if you do a shift+reload after 4) ?

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

... and you could figure out a Regression Range what may point to a Checkin explaining the Change of Behavior:
http://harthur.github.com/mozregression/

Comment 4

[Janne]

(In reply to comment #2)
> >Is there a way in Firefox 4.* - 5.* to change that behavior back to as it where ?
> A bug can be fixed but it's unknown if this is a real bug. There is not
> enough information in this report.
> 
> from the Firefox side you are doing this (right?):
> 1) open http://host1.domain.net/photos/login
That's right except a typo, it is
http://host1.domain.net/photos/

> 2) the server sends a http 401 response or do you get a page with a
> username/password form  ?
It's a 401 response

> 3) Firefox either sends the basic authentication header or a form post
> depending on 3
> 4) the server sends a html file
Firefox sends the basic authentication header.

> 
> Either there is a difference with the sent data from 3) or the html gets
> parsed differently.
> You can only find a difference in 3) with a packet trace or gecko http log
> and a difference in parsing the html can not be found without the html that
> the server sends.
> 
> Can you open about:config and change html5.parser.enable to false and try it
> again ?
Tried that, no difference.

> Please don't forget to change it back because it will break other pages.
> Does it make a difference if you do a shift+reload after 4) ?
No difference.

Comment 5

[Matthias Versen [:Matti]]

It can only be a difference in the html/JS if Gecko2.0+ submits the same information for the basic authentication as Gecko1.9.x
Can you try it again with disabled Javascript ?

We need a packet trace if that doesn't help.....

Comment 6

[Janne]

(In reply to comment #5)

> Can you try it again with disabled Javascript ?

Tried with Javascript disabled and there's no difference.

> We need a packet trace if that doesn't help.....

O.K. What type of packet trace do you suggest ?
and how do I generate it ?

Comment 7

[Matthias Versen [:Matti]]

wireshark would be an example but the problem is that it will include your hostname/IP....

Another thing:; Can you save the website and attach it (using the "add an attachment link") here after you modified the hostname in the html file ?

Comment 8

[Janne]

Attachment: apache log for firefox 3.6.18

Comment 9

[Janne]

Attachment: apache log for firefox 5.0

Comment 10

[Janne]

Attachment: http headers firefox 3.6.18

Comment 11

[Janne]

Attachment: http headers firefox 5.0

Comment 12

[Janne]

(In reply to comment #7)
> wireshark would be an example but the problem is that it will include your
> hostname/IP....

I'm not to keen on attaching a wireshark dump, it's a lot of editing to
change all occurences of hostnames/ip/password and I think I've to export
it as a text file to be able to edit it at all ?

> Another thing:; Can you save the website and attach it (using the "add an
> attachment link") here after you modified the hostname in the html file ?

Well it's not a website really. Like I said in my first post it's just a 
listing of a ftp servers directory. It's only a proxied location on the
webserver (host1), so there's nothing to save and attach.

I'm attaching http request/response headers and apache debugged logs for
Firefox-3.6.18 an Firefox-5.0 so you can see what is happening.

Comment 13

[Janne]

I would like to point out the fact that the links/directories in the generated
ftp direcory listing can be clicked and works when you are viewing the
page source. This by itself looks like a bug to me.

Comment 14

[Matthias Versen [:Matti]]

>Well it's not a website really.
What is it then ?
The html source is required, the log itself doesn't tell much.

>I would like to point out the fact that the links/directories in the generated
>ftp direcory listing can be clicked and works when you are viewing the
>page source. This by itself looks like a bug to me.

No, it doesn't have to be. a base tag could cause this.

Comment 15

[Janne]

(In reply to comment #14)
> What is it then ?

I'll try to clearify.
When you access a ftp server with firefox like this:

ftp://some_ftp_server.domain.net

You'll get a generated listing of the content on the ftp server, it's not a
html file on a web server, right ?

The difference in this case is that the ftp server (which is on the internal net) is accessed from internet by using a proxied location on a web server,
but there is still no html file involved on the web server.

It will then be accessed like this:

http://some_web_server.domain.net/proxied_location_name/

When you do this with a ftp server that's accessible by anonymous users
everything works fine, it's when you have to login with a username
the problem occur.

As I said in my first post the only thing that is set up on the
apache server is:

---- snip -----------------------------------------------
ProxyPass /photos/ ftp://host2.domain.net/photo/
ProxyPassReverse /photos/ ftp://host2.domain.net/photo/
---- snip -----------------------------------------------

So there's no html file that the user access, it's directory on a ftp server.

I've had this setup working with firefox browsers since 2007.
When I upgraded to firefox 4.0 the problem occurred.
I've also tried with different ftp servers and there's no difference.

If some of you guys have access to an apache server this is easy to tryout.
_____________________________________________________________________
Load the apache proxy modules:

proxy, proxy_connect, proxy_ftp and proxy_http

Set up apache's serverconfig with the proxy cmds like I described above.
The ftp server can reside on another host or on the same host as the
apache server.
If the ftp server is on the same server as the web server,
set up the proxied location like this:

/proxied_location_name/ ftp://localhost/some_dir/

localhost must of course listen to port 21.
____________________________________________________________________

That's it, restart apache and try it out with firefox 3.*, 4.* and 5.*.

> The html source is required, the log itself doesn't tell much.

The only html source that's involved here is the one I get when right clicking
and viewing page source and it is the same no matter wich version of firefox
I use.

I'll attach that source view soon.

> No, it doesn't have to be. a base tag could cause this.

You're probably right, it looks like the "base href" is treated differently when comparing firefox 3.* vs firefox 4/5.*.

Comment 16

[Janne]

Attachment: viewed page source

Comment 17

[Matthias Versen [:Matti]]

>You'll get a generated listing of the content on the ftp server, it's not a
>html file on a web server, right ?

It's generated by Apache in your case but the server side and from where the html comes (PHP, ASP, html file,..) doesn't matter for a browser.
 
The base Tag is relative and it seems that Firefox didn't support that until we implemented the html5 compatible way with bug 515401.
That would make thus bug invalid as it seems because we follow the html5 specification now.
Boris, can you confirm that ?

Comment 18

[Boris Zbarsky [:bzbarsky]]

Yep.  The behavior change was that we started allowing relative URIs in <base href>, per the spec change.  That href attribute value is missing a '/' at the beginning.

Janne, you might want to report this to the Apache folks; the HTML they're generating is either invalid (as actual HTML 3.2) or doesn't do what they want (as HTML 5).

Comment 19

[Janne]

I'm happy with that.

I can work around this with the auth stuff on the webserver and open up the
ftpserver for anonymous use.

I still don't get why the links work when viewing the page source, but I
wont bug you about that anymore.

Thank you for the answer.

Comment 20

[Boris Zbarsky [:bzbarsky]]

> I still don't get why the links work when viewing the page source

Arguably a bug in view-source: it always uses the document URI as the base URI, because it's not actually creating a DOM and hence doesn't do any <base> processing.

Comment 21

[Janne]

I just wanted to share what workaround I ended up with in case someone
is interested.

Downloaded the apache source and edited mod_proxy_ftp.c and removed a line
(which is creating the "base href") completely, recompiled the module with:

apxs2 -i -a -c mod_proxy_ftp.c

Replaced original mod_proxy_ftp.so with the newly compiled one,
restarted apache and everything works fine again without a "base href".

Sorry if I bugged you again ;-)