bugGNUstep - Bugs: bug #31309, URL problems with local files and...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #31309: URL problems with local files and anchors

Submitted by:  Riccardo Mottola <rmottola>
Submitted on:  Mon 11 Oct 2010 10:22:31 PM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

(Jump to the original submission Jump to the original submission)

Fri 12 Nov 2010 11:42:38 AM UTC, comment #6:

The original application wher eI got this problem now works, you state all tests pass, so we can consider this closed.

Riccardo Mottola <rmottola>
Project Member
Tue 19 Oct 2010 09:35:59 AM UTC, comment #5:

Please provide testcases (ie code to be added to the testsuite at http://svn.gna.org/gnustep/tests/testsuite/trunk/base/NSURL/) showing exactly what is still wrong.
Current testcases work identically on my OSX 10.6.4 system and GNUstep.

Richard Frith-Macdonald <CaS>
Project Member
Mon 18 Oct 2010 09:38:09 PM UTC, comment #4:

tests on Mac show that independently if test.html and test.html#foo exist on the file system, opening of test.html#foo in the URL (not escaped) will open test.html. Even if only test.html#foo exists and test.html not.
This means theat there is no heuristic dependent on which file is available, but the URL is always cleared of the part after the #.

(Fruther information was sent privately through email)

Riccardo Mottola <rmottola>
Project Member
Tue 12 Oct 2010 01:53:20 PM UTC, comment #3:

I added some tests for file parsing and tweaked NSURL to correspond exactly to OSX behavior, but I think the differences were very minor and should not have an impact on this issue.

It looks to me like OSX parses file URLs correctly ... ie it conforms to the RFCs and does NOT believe that a hash in the path separates path from fragment (ie the -path method returns the full path including the hash and anything after it, and the -fragment method returns nil).

It's possible/probable that the code is faulty (building a bad file URL), but that on OSX there is some undocumented behaviour to catch such coding errors.
eg. When loading data from a file URL, if the specified file cannot be found the class might attempt to locate the file by truncating the path at the first hash it finds.

Maybe this is even documented somewhere ... if you can find such documentation (or write some testcases to determine exactly what happens), we could change the GNUstep code to match.

For instance, if you create a URL with the path '/foo#bar' and you have two files 'foo#bar' and 'foo', which file does the data come from when you get the data from the URL?

Richard Frith-Macdonald <CaS>
Project Member
Tue 12 Oct 2010 07:19:39 AM UTC, comment #2:

All the NSLog() info is quite useful.

Can we concentrate on one thing at a time though, I would suggest starting with the behavior of the NSURL class for parsing into parts.

If, instead of (or as well as) generating NSLog entries, we could produce code in the testsuite which would generate NSURL objects representing files in different ways, and for each the code could test the return values from the various methods (-path, -fragment etc) ibn the way you did in your last comment, then we can pinpoint any differences between NSURL behavior with file URLs on OSX and GNUstep.

Once we have testsuite code to do this, we can make any modifications needed to NSURL parsing. Then, if parsing behaves the same way on botyh systems, we can look at the methods loading data from a URL, and figure out what stringWithContentsOfURL: is doing.

Richard Frith-Macdonald <CaS>
Project Member
Tue 12 Oct 2010 06:58:03 AM UTC, comment #1:

NSURL *url=[NSURL fileURLWithPath :@"/this#is a Path with % < > ?"];
NSLog(@"%@", [url path]);
NSLog(@"%@", [url fragment]);
NSLog(@"%@", [url absoluteString]);
NSLog(@"%@", [url relativeString]);
NSLog(@"%@", [url description]);

The above code executed on mac 10.4 yields:

2010-10-12 08:53:03.268 URLTest[387] /this#is a Path with % < > ?
2010-10-12 08:53:03.268 URLTest[387] (null)
2010-10-12 08:53:03.268 URLTest[387] file://localhost/this%23is%20a%20Path%20with%20%25%20%3C%20%3E%20%3F
2010-10-12 08:53:03.268 URLTest[387] file://localhost/this%23is%20a%20Path%20with%20%25%20%3C%20%3E%20%3F
2010-10-12 08:53:03.268 URLTest[387] file://localhost/this%23is%20a%20Path%20with%20%25%20%3C%20%3E%20%3F

Riccardo Mottola <rmottola>
Project Member
Mon 11 Oct 2010 10:22:31 PM UTC, original submission:

The following code works on Mac:

sourceURL = [NSURL URLWithString:@"file://localhost/Users/multix/Sites/testpage.html"];
NSLog(@"File obtained from request: %@", [NSString stringWithContentsOfURL:sourceURL]);
sourceURL = [NSURL URLWithString:@"file://localhost/Users/multix/Sites/testpage.htm#foobarAnchor"];
NSLog(@"File obtained from request: %@", [NSString stringWithContentsOfURL:sourceURL]);

being #foobarAnchor an invalid anchor inside the testpage.html, which exists: botht imes the file gets displayed.

On GNUstep, only the URL without anchor gets displayed, the second time the file is not found.

Riccardo Mottola <rmottola>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by rmottola (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 12 Nov 2010 11:42:38 AM UTCrmottolaStatusNone=>Fixed
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1