[Webkit-unassigned] [Bug 28687] New: should not pass URI fragments to libsoup

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Aug 24 14:50:00 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=28687

           Summary: should not pass URI fragments to libsoup
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: danw at gnome.org


(pointed out by reinouts on irc)

If you click on a link like "http://example.com/#comments" in WebKitGTK, it
passes the whole URI (including the fragment) to libsoup. Normally libsoup
doesn't pass the "#comments" to the remote server, but if you're using a proxy,
then it does. And some servers will return a 404 or 403 in that case because
they interpret the "#comments" as being part of the path.

The fact that libsoup's behavior changes depending on whether you use a proxy
is a libsoup bug, but you could argue about which of the two behaviors is the
buggy one. I think WebKit should not be passing fragments to libsoup; WebKit
wants the whole page back, and so it should be requesting the whole page from
libsoup, not just a portion of it. Also, it could be confusing if messages with
URIs that are not soup_uri_equal() would result in identical requests, and this
could end up tripping up things like caching, etc, as well. It seems wrong for
"soup_message_get_uri()" to return a URI with a fragment in it, since the
response body actually contains all fragments. But it would be wrong for
SoupMessage to clear the fragment from the URI itself too, since that could
trip up the app if it expected the URI to match what it had originally set it
to.

So anyway, I think ResourceHandleSoup should strip the URI fragment from the
URI as part of its process of canonicalizing it before passing it to libsoup.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list