Confirming.

Fixed on master and gnome-2-26 branches.

http://git.gnome.org/cgit/evolution/commit/?id=8b32dcadba4c705af60b1e33b24f46d97f7181d6
http://git.gnome.org/cgit/evolution/commit/?h=gnome-2-26&id=ab0c889cdf4acae85bfdcbe1bb615b84c27b06bc

Fix will be included in 2.26.2.

Thank you very much! I use that link everyday for my SAT Question of the Day =D

Reverting my solution because it breaks other more common URIs with escaped characters (bug #621721).  I'll have to reinvestigate the test case here to understand why GVFS is rejecting it.

Appearently having slash characters in the path part of the URI is illegal whether escaped (%2F) or not.  That's what GVFS is choking on.

In particular g_vfs_decode_uri() calls:

   decoded->path = g_uri_unescape_segment (hier_part_start, hier_part_end, "/");

The last argument ("/") being the set of illegal characters.  Yet my browser opens the URI just fine.  I wonder if this is a strange corner case that needs to be worked around.

Reassigning to GVFS for a second opinion.

For the record, this is not an Evolution issue because it's reproducible outside of Evolution:

$ xdg-open http://click.collegeboard.com:8080/11393308.10540.0.0.http%3A%2F%2Fapps.collegeboard.com%2Fqotd%2Fanswer.do%3FquestionId%3D963%26answerCd%3DC%26src%3DE
gvfs-open: http://click.collegeboard.com:8080/11393308.10540.0.0.http%3A%2F%2Fapps.collegeboard.com%2Fqotd%2Fanswer.do%3FquestionId%3D963%26answerCd%3DC%26src%3DE: error opening location: Operation not supported

(In reply to comment #6)
> Appearently having slash characters in the path part of the URI is illegal
> whether escaped (%2F) or not.  That's what GVFS is choking on.

Correction: Only escaped slash characters are illegal.  Obviously normal slash characters are acceptable in a path.

Perhaps g_vfs_decode_uri() should avoid decoding escaped slashes by splitting the path string using "%2F" as a separator, decoding each segment, then joining the decoded segments with "%2F" in between each?

(In reply to comment #8)
> (In reply to comment #6)
> > Appearently having slash characters in the path part of the URI is illegal
> > whether escaped (%2F) or not.  That's what GVFS is choking on.
> 
> Correction: Only escaped slash characters are illegal.  Obviously normal slash
> characters are acceptable in a path.

Where did you see that escape slash characters are illegal in the path part of the URI?

they're not illegal according to URI syntax, they're just mishandled by gvfs

(In reply to comment #9)
> Where did you see that escape slash characters are illegal in the path part of
> the URI?

See comment #6.  In g_vfs_decode_uri().

*** Bug 624883 has been marked as a duplicate of this bug. ***

*** Bug 625525 has been marked as a duplicate of this bug. ***

(In reply to comment #13)
> *** Bug 625525 has been marked as a duplicate of this bug. ***

When will the fix be available?

*** Bug 625598 has been marked as a duplicate of this bug. ***

Regarding links in emails of the form ...

http://rover.ebay.com/rover/0/e11021.m44.l1150/7?euid=6058115621199786115&loc=http%3A%2F%2Fsearch.ebay.com%2Fws%2Fsearch%2FSaleSearch%3Fcoentrypage%3Dsearch%26saendtime%3D1280374907%26sabfmts%3D1%26dfsp%3D2%26copagenum%3D1%26coaction%3Dcompare%26from%3DR9%26sotrtype%3D1%26satitle%3Dwollensak%2B-cassette%26catref%3DC6%26version%3D2%26fstype%3D1%26sacategory%3D293%26_trksid%3Dm194%26sotrvalue%3D1%26ssPageName%3DADME%3AB%3ASS%3AUS%3A1150

... there is the feeling in the ebay community that the problem is the length of the link, not the embedded URL.  Perhaps 625525 is not really the same bug as this.

Can this theory be tested?  What is the length of the longest permitted link in gnome/evolution?

The problem is the escaped slashes (%2F).

(In reply to comment #17)
> The problem is the escaped slashes (%2F).

It has nothing to do with the slashes. The problem is we're blanketly un-escaping the entire URL when it shouldn't be, without regard for the values of the parameters.

The ebay link has a perfectly valid search.ebay.com URL, including parameters, escaped and passed to the "loc" parameter of the rover.ebay.com url.  When you unescape the entire URL, including the parameters, you break it, as now the parameters of the escaped URL become parameters of the base URL.


Quoted my duplicate bug# 624883 :

The above link include a parameter named "url" which contains an escaped URL
which, including it's escaped parameters, to be passed onto the base URL.

The value of the 'url' parameter is unescaped before being passed to the
browser, thus breaking the parameters the encapsulated URL is expecting to have
passed.

In addition, you can see that any link within an email which has an escaped ampersand or other reserved character is un-escaped and becomes part of the URL.

Try this:
1. search for "this&that" on Amazon. It results and search bar show "this&that"
2. Copy the link and email it to yourself in an HTML message
3. Open same link and find now the results and search bar show only "this"

The "&that" portion just became a arbitrary parameter being passed on the URL.

Amazingly, the following link WORKS PROPERLY from within email.  It uses the escaped &loc=... construct.

http://rover.ebay.com/rover/0/e11021.m44.l1150/7?euid=5795809848878177667&loc=http%3A%2F%2Fshop.ebay.com%2F%3F_nkw%3DChassis%2520punch%26_sacat%3DSee-All-Categories%26_from%3DR40%26_trksid%3Dm194%26ssPageName%3DADME%3AB%3ASS%3AUS%3A1150

The following link STILL DOES NOT WORK

http://rover.ebay.com/rover/0/e11021.m44.l1150/7?euid=7126410313795277294&loc=http%3A%2F%2Fsearch.ebay.com%2Fws%2Fsearch%2FSaleSearch%3Fsbrsrt%3Dd%26coentrypage%3Dsearch%26saendtime%3D1280716710%26sosortorder%3D2%26copagenum%3D1%26coaction%3Dcompare%26from%3DR9%26sotrtype%3D1%26satitle%3Dcollins%26catref%3DC6%26version%3D2%26sosortproperty%3D2%26fstype%3D1%26sacategory%3D4670%26_trksid%3Dm194%26sotrvalue%3D1%26ssPageName%3DADME%3AB%3ASS%3AUS%3A1150

Does this modify the current thinking about the underlying cause of the problem?
Length issue?

This link ALSO WORKS!

http://rover.ebay.com/rover/0/e11021.m44.l1150/7?euid=7136124652194793494&loc=http%3A%2F%2Felectronics.shop.ebay.com%2FParts-Repair-%2F72404%2Fi.html%3F_catref%3D1%26_trksid%3Dm194%26ssPageName%3DADME%3AB%3ASS%3AUS%3A1150

I notice that in the links that WORK, the sequence %3A%2F%2F (  ://  )  is not split across a new line.  It IS split in links that do not work.  Coincidence???
Maybe the 'ignoring of \n at end of line' is not done properly.

We know what the bug is. It's that gvfs decodes and then re-encodes the URL rather than passing it to the server as-is.

I was waiting for someone else to ask the obvious question, but no one did, so here goes.  If you know what the problem is, why hasn't it been fixed by now?

*** Bug 592037 has been marked as a duplicate of this bug. ***

Here's my Google Chrome workaround (hack) until a proper solution is found. I'm guessing there's some research to be done to learn why or what condition was encountered leading to this regression.

This workaround will fail if the original URI has un-escaped options after an embedded escaped URI which are supposed to remain unscaped, but it still could work better than it does now, plus it allows me to open my eBay URIs.

The workaround re-escapes something which looks like a http URL at the end of another http URL.

/usr/local/bin/fixgvfsuri:
#!/usr/bin/perl
use strict;
foreach (@ARGV) {
        if (/^(http.+)(http.*)$/) {
                my $first=$1;
                my $fixed=$2;
                $fixed=~s/\%/\%25/g;
                $fixed=~s/\&/\%26/g;
                $fixed=~s/\?/\%3F/g;
                $fixed=~s/\//\%2F/g;
                $fixed=~s/\:/\%3A/g;
                $fixed=~s/\=/\%3D/g;
                print $first.$fixed."\n";
        } else {
                print $_."\n";
        }
}

Patch /opt/google/chome/google-chrome wrapper script so last line:
exec -a "$0" "$PROGDIR/chrome" "$@"

becomes:
exec -a "$0" /usr/local/bin/fixgvfsuri "$@" | xargs "$PROGDIR/chrome"

Please see Bug # 625413.  Same issue.

*** Bug 630266 has been marked as a duplicate of this bug. ***

  I filed bug 625413 in July of this year, which is clearly a duplicate of this bug. I see there hasn't been a positive post since 8-2-10. I would ask the same question as Al Schapira posted in August: If the cause of the bug is known, why   hasn't a fix been issued? It is a real headache to manually copy and paste links from e-mails into Firefox.

This bug still persists in Fedora 13.  
Linux ADS2 2.6.34.7-61.fc13.i686 #1 SMP Tue Oct 19 04:42:47 UTC 2010 i686 i686 i386 GNU/Linux

Please fix.

PLEASE PLEASE PLEASE get this bugger fixed.

My bug report # 644536 would LOVE a solution. This problem has occurred since 10.10 has been released.

Cheers, Al

The bug will be fixed when somebody provides an acceptable patch. You can speed things up by working on such a patch. Uou cannot speed things up by unloading your frustration here.

This is actually a duplicate of bug 546256. In the case for http we should indeed not try to decode the url in the URI mapper (and failing here due to the reserved chars IIRC).

*** This bug has been marked as a duplicate of bug 546256 ***