367432 - subscribe to feed button broken (tries to access feed:// url through proxy server)

Status: RESOLVED WORKSFORME

(Firefox Graveyard :: RSS Discovery and Preview, defect)

Description

[Mikel Ward]

When I go to a web page with an RSS or Atom feed (e.g. http://www.schneier.com/blog/) and click on the orange "Subscribe to feed..." button, I am taken to a URL with a feed scheme (e.g. feed://http//www.schneier.com/blog/index.rdf), which Firefox passes off to my proxy server, which returns an "Invalid URL" error.

It doesn't matter what my Feeds preference is set to, whether Preview or subscribe using Google Reader.

This used to work.  I think it stopped working when I upgraded to Firefox 2.0.0.1 from 2.0.

Comment 1

[Phil Ringnalda (:philor)]

Do you still see the same thing when you try in Firefox's safe mode <http://kb.mozillazine.org/Safe_mode>?

Comment 2

[Mikel Ward]

No, it's still broken.

What I do notice however:
1) for some reason the status bar mentions feedburner.com, despite my preferences not telling the system to use feedburner
2) entering the feed's http URL (e.g. http://www.schneier.com/blog/index.rdf) manually in the address bar does the right thing; it's just the orange RSS icon that's broken

Comment 3

[Mikel Ward]

The feedburner.com reference is harmless.  The blog URL redirects to feeds.feedburner.com.

Comment 4

[Robert Sayre]

> which Firefox passes off to my proxy server

What proxy server?

Comment 5

[Mikel Ward]

My company's web proxy server, configured via a proxy auto config file.  It's a rebranded Squid box running Squid 2.5.

I don't understand why it's even passing this request off to the proxy, it should be passing off a request to the Google web service to subscribe to the feed or showing the Firefox RSS preview, depending on which feed reader I've told Firefox to use.

Is Firefox supposed to have registered itself as the handler for feed:// links?

Comment 6

[Robert Sayre]

> 
> I don't understand why it's even passing this request off to the proxy

Nor do I. Investigating.

> 
> Is Firefox supposed to have registered itself as the handler for feed:// links?
> 

Yes.

Comment 7

[Mikel Ward]

I've got no entry in the registry under HKEY_CLASSES_ROOT\feed, which seems to be where it should be (http://msdn.microsoft.com/workshop/networking/pluggable/overview/appendix_a.asp).

What should I do to fix this?  Is there some way to do is using the Firefox UI?

Comment 8

[Robert Sayre]

(In reply to comment #7)
> 
> What should I do to fix this? 

Hopefully we'll have a patch ready very soon.

Comment 9

[Robert Sayre]

I've got additional reports of this in my inbox. Let's try to sort it out for 2.0.0.4.

Comment 10

[Maarten Brouwers]

I don't know what type of proxy I'm behind (is there an easy way to find out?), but I know that I'm behind one, and I can experience the same problem as described by Mikel Ward (both in Firefox 2.0.0.12 and the latest 3.0betas). It is not limited to a type of feed, nor feed service. I experience it both with feeds from feedburner, as well as other websites, not using feedburner; e.g. http://3voor12.vpro.nl/index.jsp and https://addons.mozilla.org/en-US/firefox/ The result of adding the latter feed is:

feed://https//addons.mozilla.org/en-US/firefox/recommended/format:rss 

removing "https//" does show the feed again, as it is supposed to.

Comment 11

[Cameron Simpson]

I am experiencing this on FF 3b5 on MacOSX, English(UK) install.
I am using a proxy. My feed handler is NetNewsWire, not Firefox.
As reported earlier, the RSS button in the location bar shows this misbehaviour.
Going manually (or via an ordinary page HREF link) to the feed's correct URL
correctly hands the feed to NetNewsWire.

So I suspect the code behind the location bar button.

This _did_ work in FF3b4.

Comment 12

[Cameron Simpson]

Any progress on this? People are going to be pretty annoyed if something this overt shows in the release candidate...

Further to comment #11 it's not just the RSS icon in the location bar; some on-page links behave the same way. Most don't, perhaps because they are plain http/https links to the feed XML, while the icon is attached to the LINK tags which I guess become feed: URLs.

Commenting on comment #10, manually removing the "feed://https//" also works to fix things up.

Comment 13

[Kevin Stanford]

The RSS icon doesn't work at all in FF3b5, and agree with comment #11 that this is a change from FF3b4.  Where I differ from comment #11 is that going manually to the feed's correct URL doesn't work either.  I've tested multiple feeds of different types, all of which work just fine when entered into IE7's location bar, just not in FF3b5.  Whether using the URL or the RSS icon, the browser gives the appearance of loading the page -- the tab title briefly changes to "Loading..." -- but ultimately nothing happens.

I use Google Reader, if that matters.

Comment 14

[Gary]

(In reply to comment #13)
Yes, I see same problems after upgrading to FF3b5. I too use Google reader, but will see if this is broken irrespective of what reader I use. Currently, I am manually adding links to Google reader by finding rss/xml/syndication link on any page.

Comment 15

[Jeremy]

Not sure why this hasn't been commented on since April, but I'm having the same issue in FF3RC2.

I'm using Live Bookmarks to handle web feeds. Feed URLs are accessed as "feed://http//" but removing the http// doesn't help.

When this happens, FF freezes for about 45 seconds, then I get a 502 proxy error - I'm behind a company proxy.

This happens every time I use the FF RSS button, but only sometimes if I use the feed link on a webpage.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

Comment 17

[amhoyle]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 (.NET CLR 3.5.30729)

This problem is still occurring in Firefox 3.0.4 as reported in Bug 465202.

Comment 19

[amhoyle]

What sort of timescale does it take for things like this to get fixed and does anyone know a workaround in the meantime?

Comment 20

[Daniel Veditz [:dveditz]]

This keeps getting kicked down the road -- are we going to fix it in an upcoming release or not?

Comment 21

[Dave Townsend [:mossop] (PTO until Aug 21st)]

This doesn't seem serious and common enough for us to block 3.1 on it at this stage. Would be nice to see a fix though.

Comment 22

[amhoyle]

Maybe not serious but it affects anyone who uses a proxy server, which I expect is quite a large proportiion of users!  I agree a fix would be in order.  Reading about, it seems it used to work so hopefully a fix should be fairly simple?

Comment 23

[Phil Ringnalda (:philor)]

It would only be simple if we simply wanted to throw away what gave us the problem, the code which lets us tell the difference between "you followed a link to something which isn't served with a feed mime-type, which looks a little like a feed but might be a false positive" and "you clicked the addressbar icon for an autodiscovered feed, so whether or not it looks like a feed it should be treated as one."

Nor is it simple to reproduce, or "anyone who uses a proxy server," since I installed Squid, told Fx to use it for all protocols, and didn't see this bug. Unfortunately, I don't know enough about proxy servers to even ask you the right question to discover that it's the result of something in your PAC file, or it's the result of a bug in our networking code's support of PAC or of proxies, or what.

Comment 24

[[:Cww]]

Ok, so my roommate says that pretty much everyone he knows using the PAC at HP has this problem (he works there, and it happens on his and his co-worker's computers) using 3.0.  Manually specifying the proxy, however, works fine.

Comment 25

[Hiroyuki Ikezoe (:hiro)]

Attachment: Proposed patch

I am not sure URI_NORELATIVE is appropriate for feed protocol, but the patch kicks this bug off.

Comment 26

[amhoyle]

Glad someone attempted a fix.  I tried this fix by changing the appropriate lines in the FeedConvertor.js file on my machine.

There seem to be a few problems:

1.When the feed button is clicked, it now comes up with a Launch Application handler with Outlook (listed for my machine) but it won't preview in Firefox which is the what the default handler for feeds is set to.
2. Navigating to this link http://www.bbc.co.uk/home/features/d/snippet.xml in the patched code no longer loads a preview of the feed like it did in the old code.
3. I think the link to the feed is still wrong.  Outlook reports 
http://http:/www.bbc.co.uk/home/features/d/snippet.xml, when it should be
http://www.bbc.co.uk/home/features/d/snippet.xml

Looks like at least you're in the right area with the patch.

Comment 27

[Hiroyuki Ikezoe (:hiro)]

Thank you for testing.

(In reply to comment #26)
> 1.When the feed button is clicked, it now comes up with a Launch Application
> handler with Outlook (listed for my machine) but it won't preview in Firefox
> which is the what the default handler for feeds is set to.

Sorry, I can not reproduce this.

> 2. Navigating to this link http://www.bbc.co.uk/home/features/d/snippet.xml in
> the patched code no longer loads a preview of the feed like it did in the old
> code.

I guess browser.feed.handler in your prefs seems not to be "ask".

> 3. I think the link to the feed is still wrong.  Outlook reports 
> http://http:/www.bbc.co.uk/home/features/d/snippet.xml, when it should be
> http://www.bbc.co.uk/home/features/d/snippet.xml

In my environment, URI is feed://www.bbc.co.uk/home/features/d/snippet.xml (indeed I do not use Outlook), but anyway this behavior always happens without my patch. This should be opened as a new bug.

Comment 28

[Hiroyuki Ikezoe (:hiro)]

Didn't somebody else test the patch?

Comment 29

[YUKI "Piro" Hiroshi]

You MUST use PAC file (which is auto configuration script for proxy),
to reproduce the problem. For example:

user_pref("network.proxy.type", 2);
user_pref("network.proxy.autoconfig_url", "file:///home/myname/proxy.pac");

-----< contents of /home/myname/proxy.pac >-------
function FindProxyForURL(url, host) {

  return "PROXY host-name.or.ip-address.of.my-proxy" ;

}

--------------------------------------------------

Comment 30

[YUKI "Piro" Hiroshi]

(In reply to comment #29)
> You MUST use PAC file (which is auto configuration script for proxy),
> to reproduce the problem. For example:

More descriptions; The problem appear only when I use proxies with PAC file. If I use a proxy by network.proxy.type=1, I didn't see the problem. After I changed the proxy setting to use PAC file, I saw the error page output by the proxy even if PAC script returned just same proxy.

After I applied Hiroyuki's patch, the problem didn't appear anymore.

Comment 31

[Zdravko Spoljar]

(Add to comment #29)

that is already known and reported as bug 392179, 2 years ago :)

Comment 33

[Hiroyuki Ikezoe (:hiro)]

Comment on attachment 366708 [details] [diff] [review]
Proposed patch

Gavin, could you please take look into this patch?

Comment 34

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 366708 [details] [diff] [review]
Proposed patch

URI_NORELATIVE seems like it probably makes sense for feed:, though I'm not sure offhand why it fixes this bug.

Before attempting to figure that out, though, I can point out right away that replacing the default HTTP nsIProtocolHandler flags probably isn't correct. Don't you want to return |this._http.protocolFlags | Ci.nsIProtocolHandler.URI_NORELATIVE| instead?

Comment 35

[Julián Ortega]

Same here, using FF3.5.2 on WinXP (Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)), behind a proxy:

"ERROR
The requested URL could not be retrieved

While trying to retrieve the URL: feed://http//elespectador.com/rss.xml

The following error was encountered:

    * Invalid URL 

Some aspect of the requested URL is incorrect. Possible problems:

    * Missing or incorrect access protocol (should be `http://'' or similar)
    * Missing hostname
    * Illegal double-escape in the URL-Path
    * Illegal character in hostname; underscores are not allowed 

Your cache administrator is root".

Comment 37

[glen.a.ritchie]

WinXP - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8.

Same issue.

Workaround:
Edit the proxy.pac(or ask your cache admin) to include this:

if (url.substring(0, 5) == "feed:")
  return "DIRECT";

Comment 38

[Kartik Agaram]

I'm seeing this problem at home. No proxy, no pac file, no windows. Should I file a separate bug?

Comment 39

[Phil Ringnalda (:philor)]

Yes

Comment 40

[Othmar]

So, I'm now using Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0 and this bug is still there.

I can summarize some comments made before:

When a proxy is set by name and port the rss subscription works. BUT, when a proxy configuration is used the URL submitted to the proxy is just plain invalid.

I used this most simple proxypac file:
function FindProxyForURL(url, host) {
   return "PROXY 127.0.0.1:8080";
}

The URL sent to the proxy is syntactically incorrect, for example:
GET feed://http//www.tagesanzeiger.ch/rss_ticker.html
The host header field in the request looks like this: "Host: http"
No wonder no proxy can support this invalid request.

I fix would be very appreciated, eventually

Regards

Comment 41

[Hiroyuki Ikezoe (:hiro)]

Attachment: Just return Ci.nsIProtocolHandler.URI_NORELATIVE instead

I am very sorry that I have not taken any action for this issue.

Now I have no test environment this issue. I hope someone helps me.

Comment 42

[Victor Engmark]

Confirmed at https://www.eff.org/https-everywhere with Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110905 Ubuntu/10.10 (maverick) Firefox/3.6.22

Comment 43

[:Gavin Sharp [email: [e-mail]]]

Attachment: potential (untested) patch

URI_NORELATIVE shouldn't have an impact on proxy behavior, AFAIK. But I think it makes sense to mark the "feed" protocol handler as not proxyable (the underlying HTTP protocol handler would still be).

Is anyone able to still reproduce this bug and test this patch?

Comment 44

[:Gavin Sharp [email: [e-mail]]]

(I can provide test builds as needed.)

Comment 45

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch

Rather than delegating to the HTTP flags, let's just specify our own. The default HTTP protocol flags are URI_LOADABLE_BY_ANYONE | ALLOWS_PROXY | ALLOWS_PROXY_HTTP, so the only one we need to set is URI_LOADABLE_BY_ANYONE.

(I considered also setting URI_NOAUTH and URI_NORELATIVE, since I think those are appropriate for feed:, but I couldn't actually find where those flags are observed, and so I avoided making that unrelated change.)

Comment 46

[:Gavin Sharp [email: [e-mail]]]

I pushed that patch to try:
https://tbpl.mozilla.org/?tree=Try&rev=ec47961d52c6

A linux64 build should be here shortly:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-ec47961d52c6/

If anyone could test it and confirm that it fixes this bug, that would be great.

Comment 47

[:Gavin Sharp [email: [e-mail]]]

alavaliant, any chance you're able to test this one as well?

Comment 48

[alavaliant]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #47)
> alavaliant, any chance you're able to test this one as well?

I've just tried running your build https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-ec47961d52c6/   and visited http://www.schneier.com/blog/    clicking on 'subscribe to this page...' option seemed to work as far as I could see,  it's shown up in my bookmarks atleast and if I select it there is a list of titles under it     (so my work's authenticated proxy server seems to work fine with subscribing to rss feeds with that build atleast.  - I'm taking it that was what you needed testing from what I can see skimming through this bug?)

Comment 49

[:Gavin Sharp [email: [e-mail]]]

(In reply to alavaliant from comment #48)
Thanks again, that's very helpful. If you try those same steps in a Firefox build without my patch (e.g. the latest release, or beta, or Nightly), is it broken as described in comment 0?

Comment 50

[alavaliant]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #49)
> (In reply to alavaliant from comment #48)
> Thanks again, that's very helpful. If you try those same steps in a Firefox
> build without my patch (e.g. the latest release, or beta, or Nightly), is it
> broken as described in comment 0?

I've just tried using the official version 20 x64 build under Linux and the same steps actually seem to work the same under it so I guess my first test doesn't show too much since it doesn't look I'm experiencing the original bug using version 20 of firefox against my proxy server.

Comment 51

[:Gavin Sharp [email: [e-mail]]]

Ah, bummer! On the bright side, it's possible this issue is no longer occurring due to some other change.

Comment 52

[:Gavin Sharp [email: [e-mail]]]

Absent anyone able to reproduce this, I guess we'll have to resolve. But please do reopen if you still see this!