I've updated the ticket with both the test files and the proposed patch to resolve it. (http://dev.jquery.com/ticket/3808)
The patch includes spicyj's suggested code with a minor tweak. In Javascript, string.replace(...) does not edit the string it operates on, but merely returns a copy with the suggested changes. As such, I set the result equal to the string being operated upon by the search- and-replace regular expression. Cheers. - Gavin On Mar 3, 9:51 pm, "d3r1v3d (Gavin Mulligan)" <[email protected]> wrote: > Having said that, I just realized what you were saying and you're > absolutely right, spicyj. Fragments (or anchors, as I called them) go > at the end, according to the official W3C spec (http://www.w3.org/TR/ > WD-html40-970708/htmlweb.html). So, your patch is superior to mine. :) > > - Gavin > > On Mar 3, 9:47 pm, "d3r1v3d (Gavin Mulligan)" <[email protected]> > wrote: > > > In the code I suggested, I attempt to match on a '?' to see if a query > > string is present. If so, the regular expression grabs all URL > > segments starting with '#' and ending with '?' and replaces them with > > '?'. Otherwise, the other branch yanks everything from the '#' > > onwards. > > > I wanted to keep the query string intact since I figured some people > > might prefer to craft GET request URLs and insert their data directly > > into the query string instead of putting it in the data parameter. Not > > something I'd do, but didn't want to break anything. :) > > > - Gavin > > > On Mar 3, 9:01 pm, spicyj <[email protected]> wrote: > > > > Doesn't the fragment go after the query string? > > > > Assuming that's right, here's a patch that's a bit simpler: > > > >http://pastie.org/406716 > > > > ~spicyj > > > > On Mar 3, 5:48 pm, "d3r1v3d (Gavin Mulligan)" <[email protected]> > > > wrote: > > > > > Hey John, > > > > > Sorry I'm not at my machine with SVN access or I'd provide a diff of > > > > my proposed change for fixing this. > > > > > In (http://dev.jquery.com/browser/trunk/jquery/src/ajax.js), within > > > > the ajax method (starting line 174), I'd recommend adding the > > > > following lines: > > > > > // START > > > > if (s.url.match(/\?/)) > > > > { > > > > s.url.replace(/#(.*)?\?/g, '?'));} > > > > > else > > > > { > > > > s.url.replace(/#(.*)?/g, '');} > > > > > // END > > > > > Essentially, this yanks any anchor tag from a given URL while > > > > preserving the query string (if one exists). Additionally, an if block > > > > could be placed around this code to do an initial match for hash marks > > > > (#) to test for the existence of anchors in the first place, I just > > > > left it out since it seemed a tad excessive. Hope this helps. > > > > > - Gavin > > > > > On Mar 3, 4:46 pm, John Resig <[email protected]> wrote: > > > > > > Hey Gavin - > > > > > > Thanks for the fact-finding, that definitely clears things up - I'll > > > > > see if I can fix this for 1.3.3. > > > > > > --John > > > > > > On Tue, Mar 3, 2009 at 4:40 PM, d3r1v3d (Gavin Mulligan) > > > > > > <[email protected]> wrote: > > > > > > > For kicks, I've been looking into the causes behind the problem this > > > > > > ticket poses. I've managed to duplicate the error in the test script > > > > > > that the ticket poster provided (http://pixeline.be/experiments/ > > > > > > jquerybeta/test2.html). > > > > > > > Essentially, the problem is that Ajax GET requests (haven't tried > > > > > > with > > > > > > POST) to a URL which happens to include an anchor ('#') consistently > > > > > > fail with HTTP 404 status errors (Document Not Found) in Internet > > > > > > Explorer (tested with 7.0.5730.13), while these same requests are > > > > > > processed just fine in Firefox 3, Chrome, et al. > > > > > > > After putzing around a bit, I noticed something interesting. When I > > > > > > ran the test case in Internet Explorer, my Apache error log > > > > > > displayed > > > > > > the following error: > > > > > > [Tue Mar 03 15:59:30 2009] [error] [client ***.**.**.**] File does > > > > > > not > > > > > > exist: /<path to web-server>/dummy.html#love, referer: ... > > > > > > > I did not get this error with the other browsers that successfully > > > > > > execute the call to load(). > > > > > > > Case in point, it seems that, with the IE ajax request, the anchor > > > > > > (and anchor name) is not correctly parsed out of the base document's > > > > > > file name when it is served. This would be akin to a web server > > > > > > receiving a get request for webPage.html with parameters foo=bar and > > > > > > searching for a document on the local file-system named '/apache/ > > > > > > htdocs/webPage.html?foo=bar'. Obviously any query strings (or in > > > > > > this > > > > > > case, anchor data) should be removed from the URL before this point. > > > > > > > I would argue, however, that these anchors have no place in Ajax > > > > > > requests to begin with, as the entire dummy.html document will be > > > > > > retrieved and returned in the Ajax response, thus eliminating the > > > > > > need > > > > > > for an anchor tag. However, I would propose that the jQuery Ajax > > > > > > component could be extended to parse out any erroneous anchor tags > > > > > > from request URLs so that this is no longer a problem in the future. > > > > > > > - Gavin > > > > > > > (I apologize if I seem overly verbose, just want to get the facts > > > > > > out) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
