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

Group
 
 

bug #31309: URL problems with local files and anchors

Submitter:  Riccardo Mottola <rmottola>
Submitted:  Mon 11 Oct 2010 10:22:31 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-11-12 rmottola StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code