[vwnc] URLWithPath>>, implementation seems odd

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[vwnc] URLWithPath>>, implementation seems odd

cdavidshaffer
Why does URLWithPath>>, drop the last path element before appending a
new one?  It makes things like this:

'http://www.someplace.net/dog/cat/frog' , 'elephant'

drop the last path element (frog) and produce
http://www.someplace.net/dog/cat/elephant.  This generally seems like
the principle of greatest surprise at work.  I guess I can recreate the
developer's thinking...what if this isn't a path to a directory?...but
that seems contrary to the meaning of "," in general.  Any chance to
have a less surprising implementation of this operator?  For now I'm
stuck with URLWithPath>>withComponent:

David

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] URLWithPath>>, implementation seems odd

Michael Lucas-Smith-2
This is actually part of the URI spec. If you knock up a webpage that
has <a href="elephant.html">elephants!!!!</a> in it and put it in a file
called frog.html at /dog/cat/ then the webbrowser will treat that link
as /dog/cat/elephant.html - so despite being a little surprising at
first, it is consistent with the spec and the observed uses of the spec.

Cheers,
Michael

C. David Shaffer wrote:

> Why does URLWithPath>>, drop the last path element before appending a
> new one?  It makes things like this:
>
> 'http://www.someplace.net/dog/cat/frog' , 'elephant'
>
> drop the last path element (frog) and produce
> http://www.someplace.net/dog/cat/elephant.  This generally seems like
> the principle of greatest surprise at work.  I guess I can recreate the
> developer's thinking...what if this isn't a path to a directory?...but
> that seems contrary to the meaning of "," in general.  Any chance to
> have a less surprising implementation of this operator?  For now I'm
> stuck with URLWithPath>>withComponent:
>
> David
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>  

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] URLWithPath>>, implementation seems odd

cdavidshaffer
Michael Lucas-Smith wrote:
> I'm not seeing your point... I guess I need something a bit clearly to
> show me how we've got it wrong.
>
> 'fido/' asURI, 'dog' -> 'fido/dog'
> 'fido' asURI, 'dog' -> 'dog'
>
> We assume the LHS of the #, is the base. How you come to decide what
> your base is is up to you.
>
Oops, bringing this back on list since I think it is resolved.

I started typing a nice long response here only to discover that VW
seems to correctly implements section 4 of RFC1808.  I thought that it
incorrectly handled URL's with an ending slash but it doesn't.  Turned
out to be a bug in my code (returning the URL without the trailing
slash).   Sorry for the confusion.

David

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc