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 -~----------~----~----~----~------~----~------~--~---
