Re: My eyes are failing me.

[Mike Abdullah]

> On 22 Feb 2019, at 23:19, Jens Alfke  wrote:
> 
> 
> 
>> On Feb 22, 2019, at 1:07 PM, Alex Zavatone  wrote:
>> 
>> It should not show the /api in the description of the URL if it is not going 
>> to use it in any call using that URL.  
> 
> The .baseURL property returns the original URL with the /api path.
> 
>> It’s outright misleading and there is nothing in the class docs for NSURL or 
>> in the header that indicate this is the intended behavior.
> 
> I agree it’s weird. I suspect it reflects an implementation where a relative 
> URL is stored as the relative path plus a pointer to the base NSURL object … 
> but that’s not really relevant to anyone using it.
> 
> It’s been this way forever, or at least since 2001. Feel free to file a 
> Radar. But it’s just the .description, so if you ignore that property you’ll 
> be OK.


Consider writing something which parses a format like HTML. Inside the 
document, URLs may be specified as relative strings to some base URL, rather 
than to an absolute URL. e.g. this:

path=“foo/bar.html”

Is interpreted as a path relative to the base URL of the HTML document.

For whatever reason, Apple have chosen to implement NSURL/CFURL to represent 
that scenario, rather than storing everything as absolute URLs.

Mike.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: My eyes are failing me.

[Alex Zavatone]

Yeah, but if you read the docs for NSURL, part of them say that a trailing 
slash is added automatically or else inconsistent results would be created.  
Except here it chooses to ignore that and drop the end of the URL back to the 
last / , while still displaying it in the description for the instance and 
ignoring it in the absoluteURL for the instance.

Yea! Fun times!

Now I remember while I rolled my own methods for building URLs a few years ago. 
 

Argh.

Thanks everyone.  

(Alex mutters something about going back to 6502 assembly for his own sanity.)

Sent from my iPad

> On Feb 22, 2019, at 12:55 PM, Steve Christensen  wrote:
> 
> Alex, is there any reason you couldn’t have used one of these?
> 
> [self.sharedData.webServicesURL URLByAppendingPathComponent:@"login"]
> [self.sharedData.webServicesURL URLByAppendingPathComponent:@"login" 
> isDirectory:{YES|NO}]
> 
> 
>> On Feb 22, 2019, at 9:40 AM, Alex Zavatone  wrote:
>> 
>> There are 2 problems here.
>> 
>> The description is non standard and misleading and the /api string is 
>> stripped from the URL that it indicates it will use in that URL.  Look.
>> 
>> (lldb) po [[NSURL URLWithString:@"/login" 
>> relativeToURL:self.sharedData.webServicesURL] absoluteURL]
>> https://home-qa.mrcooper.com/login
>> 
>> (lldb) po [NSURL URLWithString:@"/login" 
>> relativeToURL:self.sharedData.webServicesURL] 
>> /login -- https://home-qa.mrcooper.com/api
>> 
>> See how in the top output that /api is stripped from the URL that it will 
>> use while it is displayed in the output on the bottom?
>> 
>> Damn misleading.  
>> 
>> 
>> 
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Feb 22, 2019, at 11:24 AM, Alex Zavatone  wrote:
>>> 
>>> Of course I should have said, “produces what appears to be an incorrect 
>>> result.”
>>> 
>>> Have I tried it? No.  I have not because it is telling me that the url I 
>>> tried to create is nothing like the URL I tried to create.
>>> 
>>> Spending some time looking at it this morning and testing against the 
>>> working string, it is apparent that the /api gets stripped off the URL when 
>>> using relativeToURL.  Look at this.
>>> 
>>> (lldb) po self.sharedData.webServices
>>> home-qa.mrcooper.com/api
>>> 
>>> (lldb) po self.sharedData.webServicesURL
>>> https://home-qa.mrcooper.com/api
>>> 
>>> (lldb) po [[NSURL URLWithString:[NSString stringWithFormat:@"%@%@%@", 
>>> @"https://;, self.sharedData.webServices, @"/login"]] absoluteURL]
>>> https://home-qa.mrcooper.com/api/login
>>> 
>>> (lldb) po [[NSURL URLWithString:@"/login" 
>>> relativeToURL:self.sharedData.webServicesURL] absoluteURL]
>>> https://home-qa.mrcooper.com/login
>>> 
>>> See how relativeToURL: strips off the /api text from the URL?
>>> 
>>> 
>>> So strange why they thought it a good idea to output the description and 
>>> debugDescription that way AND strip off part of the URL.
>>> 
>>> Argh.  Thanks for the second (and third) set of eyes.
>>> Alex Zavatone
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Feb 22, 2019, at 10:48 AM, Jens Alfke  wrote:
 
 
 
> On Feb 22, 2019, at 8:39 AM, Alex Zavatone  wrote:
> 
> self.loginURL = [NSURL URLWithString:@"/login" 
> relativeToURL:self.sharedData.webServicesURL]; // // WHY does this not 
> work? It does "/login -- https://qa-home.mrcooper.com/api;
 
 Because NSURL’s .description property has a stupid way of printing a 
 relative URL.
 
 The actual URL is correct, as you’ll see if you do something like `po 
 self.loginURL.absoluteString`. It should return ` 
 https://qa-home.mrcooper.com/login`.
 
 Moral of the story: Always use .absoluteString to convert an NSURL to a 
 string, never .description or something that calls it implicitly.
 
 —Jens
> 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: My eyes are failing me.

[Jens Alfke]

> On Feb 22, 2019, at 1:07 PM, Alex Zavatone  wrote:
> 
> It should not show the /api in the description of the URL if it is not going 
> to use it in any call using that URL.  

The .baseURL property returns the original URL with the /api path.

> It’s outright misleading and there is nothing in the class docs for NSURL or 
> in the header that indicate this is the intended behavior.

I agree it’s weird. I suspect it reflects an implementation where a relative 
URL is stored as the relative path plus a pointer to the base NSURL object … 
but that’s not really relevant to anyone using it.

It’s been this way forever, or at least since 2001. Feel free to file a Radar. 
But it’s just the .description, so if you ignore that property you’ll be OK.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: My eyes are failing me.

[Alex Zavatone]

It should not show the /api in the description of the URL if it is not going to 
use it in any call using that URL.  It’s outright misleading and there is 
nothing in the class docs for NSURL or in the header that indicate this is the 
intended behavior.

Sent from my iPad

> On Feb 22, 2019, at 12:02 PM, "lars.sonchocky-helld...@hamburg.de" 
>  wrote:
> 
> 
> 
>> Am 22.02.2019 um 18:40 schrieb Alex Zavatone :
>> 
>> There are 2 problems here.
>> 
>> The description is non standard and misleading and the /api string is 
>> stripped from the URL that it indicates it will use in that URL.  Look.
>> 
>> (lldb) po [[NSURL URLWithString:@"/login" 
>> relativeToURL:self.sharedData.webServicesURL] absoluteURL]
>> https://home-qa.mrcooper.com/login
>> 
>> (lldb) po [NSURL URLWithString:@"/login" 
>> relativeToURL:self.sharedData.webServicesURL] 
>> /login -- https://home-qa.mrcooper.com/api
>> 
>> See how in the top output that /api is stripped from the URL that it will 
>> use while it is displayed in the output on the bottom?
>> 
>> Damn misleading.  
> 
> That is not misleading, that is how relative URLs are supposed to work. You 
> should have done:
> 
>  [[NSURL URLWithString:@"login" relativeToURL:self.sharedData.webServicesURL] 
> absoluteURL] with self.sharedData.webServicesURL being: 
> „https://home-qa.mrcooper.com/api/„
> 
> for more information please refer to: 
> http://webreference.com/html/tutorial2/3.html
> 
> 
> regards,
> 
>   Lars
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: My eyes are failing me.

[Alex Zavatone]

That is utterly bizarre.

Sent from my iPad

> On Feb 22, 2019, at 12:02 PM, "lars.sonchocky-helld...@hamburg.de" 
>  wrote:
> 
> 
> 
>> Am 22.02.2019 um 18:40 schrieb Alex Zavatone :
>> 
>> There are 2 problems here.
>> 
>> The description is non standard and misleading and the /api string is 
>> stripped from the URL that it indicates it will use in that URL.  Look.
>> 
>> (lldb) po [[NSURL URLWithString:@"/login" 
>> relativeToURL:self.sharedData.webServicesURL] absoluteURL]
>> https://home-qa.mrcooper.com/login
>> 
>> (lldb) po [NSURL URLWithString:@"/login" 
>> relativeToURL:self.sharedData.webServicesURL] 
>> /login -- https://home-qa.mrcooper.com/api
>> 
>> See how in the top output that /api is stripped from the URL that it will 
>> use while it is displayed in the output on the bottom?
>> 
>> Damn misleading.  
> 
> That is not misleading, that is how relative URLs are supposed to work. You 
> should have done:
> 
>  [[NSURL URLWithString:@"login" relativeToURL:self.sharedData.webServicesURL] 
> absoluteURL] with self.sharedData.webServicesURL being: 
> „https://home-qa.mrcooper.com/api/„
> 
> for more information please refer to: 
> http://webreference.com/html/tutorial2/3.html
> 
> 
> regards,
> 
>   Lars
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: My eyes are failing me.

[Steve Christensen]

Alex, is there any reason you couldn’t have used one of these?

[self.sharedData.webServicesURL URLByAppendingPathComponent:@"login"]
[self.sharedData.webServicesURL URLByAppendingPathComponent:@"login" 
isDirectory:{YES|NO}]


> On Feb 22, 2019, at 9:40 AM, Alex Zavatone  wrote:
> 
> There are 2 problems here.
> 
> The description is non standard and misleading and the /api string is 
> stripped from the URL that it indicates it will use in that URL.  Look.
> 
> (lldb) po [[NSURL URLWithString:@"/login" 
> relativeToURL:self.sharedData.webServicesURL] absoluteURL]
> https://home-qa.mrcooper.com/login
> 
> (lldb) po [NSURL URLWithString:@"/login" 
> relativeToURL:self.sharedData.webServicesURL] 
> /login -- https://home-qa.mrcooper.com/api
> 
> See how in the top output that /api is stripped from the URL that it will use 
> while it is displayed in the output on the bottom?
> 
> Damn misleading.  
> 
> 
> 
> 
> 
> 
> Sent from my iPad
> 
>> On Feb 22, 2019, at 11:24 AM, Alex Zavatone  wrote:
>> 
>> Of course I should have said, “produces what appears to be an incorrect 
>> result.”
>> 
>> Have I tried it? No.  I have not because it is telling me that the url I 
>> tried to create is nothing like the URL I tried to create.
>> 
>> Spending some time looking at it this morning and testing against the 
>> working string, it is apparent that the /api gets stripped off the URL when 
>> using relativeToURL.  Look at this.
>> 
>> (lldb) po self.sharedData.webServices
>> home-qa.mrcooper.com/api
>> 
>> (lldb) po self.sharedData.webServicesURL
>> https://home-qa.mrcooper.com/api
>> 
>> (lldb) po [[NSURL URLWithString:[NSString stringWithFormat:@"%@%@%@", 
>> @"https://;, self.sharedData.webServices, @"/login"]] absoluteURL]
>> https://home-qa.mrcooper.com/api/login
>> 
>> (lldb) po [[NSURL URLWithString:@"/login" 
>> relativeToURL:self.sharedData.webServicesURL] absoluteURL]
>> https://home-qa.mrcooper.com/login
>> 
>> See how relativeToURL: strips off the /api text from the URL?
>> 
>> 
>> So strange why they thought it a good idea to output the description and 
>> debugDescription that way AND strip off part of the URL.
>> 
>> Argh.  Thanks for the second (and third) set of eyes.
>> Alex Zavatone
>> 
>> 
>> Sent from my iPad
>> 
>>> On Feb 22, 2019, at 10:48 AM, Jens Alfke  wrote:
>>> 
>>> 
>>> 
 On Feb 22, 2019, at 8:39 AM, Alex Zavatone  wrote:
 
 self.loginURL = [NSURL URLWithString:@"/login" 
 relativeToURL:self.sharedData.webServicesURL]; // // WHY does this not 
 work? It does "/login -- https://qa-home.mrcooper.com/api;
>>> 
>>> Because NSURL’s .description property has a stupid way of printing a 
>>> relative URL.
>>> 
>>> The actual URL is correct, as you’ll see if you do something like `po 
>>> self.loginURL.absoluteString`. It should return ` 
>>> https://qa-home.mrcooper.com/login`.
>>> 
>>> Moral of the story: Always use .absoluteString to convert an NSURL to a 
>>> string, never .description or something that calls it implicitly.
>>> 
>>> —Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: My eyes are failing me.

[Jens Alfke]

> On Feb 22, 2019, at 9:40 AM, Alex Zavatone  wrote:
> 
> The description is non standard and misleading and the /api string is 
> stripped from the URL that it indicates it will use in that URL.


You gave it an absolute path, “/login”. This has exactly the same meaning as an 
absolute filesystem path — if you’re in “/api” and type “cd /login”, you don’t 
end up in “/api/login”.

(Yes, I know, it’s a relative URL with an absolute path. URLs are weird due to 
the two-level namespace of domains and paths…)

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: My eyes are failing me.

[lars.sonchocky-helld...@hamburg.de]

> Am 22.02.2019 um 18:40 schrieb Alex Zavatone :
> 
> There are 2 problems here.
> 
> The description is non standard and misleading and the /api string is 
> stripped from the URL that it indicates it will use in that URL.  Look.
> 
> (lldb) po [[NSURL URLWithString:@"/login" 
> relativeToURL:self.sharedData.webServicesURL] absoluteURL]
> https://home-qa.mrcooper.com/login 
> 
> (lldb) po [NSURL URLWithString:@"/login" 
> relativeToURL:self.sharedData.webServicesURL] 
> /login -- https://home-qa.mrcooper.com/api 
> 
> See how in the top output that /api is stripped from the URL that it will use 
> while it is displayed in the output on the bottom?
> 
> Damn misleading.  

That is not misleading, that is how relative URLs are supposed to work. You 
should have done:

 [[NSURL URLWithString:@"login" relativeToURL:self.sharedData.webServicesURL] 
absoluteURL] with self.sharedData.webServicesURL being: 
„https://home-qa.mrcooper.com/api/„

for more information please refer to: 
http://webreference.com/html/tutorial2/3.html


regards,

Lars
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: My eyes are failing me.

[Alex Zavatone]

There are 2 problems here.

The description is non standard and misleading and the /api string is stripped 
from the URL that it indicates it will use in that URL.  Look.

(lldb) po [[NSURL URLWithString:@"/login" 
relativeToURL:self.sharedData.webServicesURL] absoluteURL]
https://home-qa.mrcooper.com/login
 
(lldb) po [NSURL URLWithString:@"/login" 
relativeToURL:self.sharedData.webServicesURL] 
/login -- https://home-qa.mrcooper.com/api
 
See how in the top output that /api is stripped from the URL that it will use 
while it is displayed in the output on the bottom?

Damn misleading.  






Sent from my iPad

> On Feb 22, 2019, at 11:24 AM, Alex Zavatone  wrote:
> 
> Of course I should have said, “produces what appears to be an incorrect 
> result.”
> 
> Have I tried it? No.  I have not because it is telling me that the url I 
> tried to create is nothing like the URL I tried to create.
> 
> Spending some time looking at it this morning and testing against the working 
> string, it is apparent that the /api gets stripped off the URL when using 
> relativeToURL.  Look at this.
> 
> (lldb) po self.sharedData.webServices
> home-qa.mrcooper.com/api
> 
> (lldb) po self.sharedData.webServicesURL
> https://home-qa.mrcooper.com/api
> 
> (lldb) po [[NSURL URLWithString:[NSString stringWithFormat:@"%@%@%@", 
> @"https://;, self.sharedData.webServices, @"/login"]] absoluteURL]
> https://home-qa.mrcooper.com/api/login
> 
> (lldb) po [[NSURL URLWithString:@"/login" 
> relativeToURL:self.sharedData.webServicesURL] absoluteURL]
> https://home-qa.mrcooper.com/login
> 
> See how relativeToURL: strips off the /api text from the URL?
> 
> 
> So strange why they thought it a good idea to output the description and 
> debugDescription that way AND strip off part of the URL.
> 
> Argh.  Thanks for the second (and third) set of eyes.
> Alex Zavatone
> 
> 
> Sent from my iPad
> 
>> On Feb 22, 2019, at 10:48 AM, Jens Alfke  wrote:
>> 
>> 
>> 
>>> On Feb 22, 2019, at 8:39 AM, Alex Zavatone  wrote:
>>> 
>>> self.loginURL = [NSURL URLWithString:@"/login" 
>>> relativeToURL:self.sharedData.webServicesURL]; // // WHY does this not 
>>> work? It does "/login -- https://qa-home.mrcooper.com/api;
>> 
>> Because NSURL’s .description property has a stupid way of printing a 
>> relative URL.
>> 
>> The actual URL is correct, as you’ll see if you do something like `po 
>> self.loginURL.absoluteString`. It should return ` 
>> https://qa-home.mrcooper.com/login`.
>> 
>> Moral of the story: Always use .absoluteString to convert an NSURL to a 
>> string, never .description or something that calls it implicitly.
>> 
>> —Jens
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: My eyes are failing me.

[Alex Zavatone]

Of course I should have said, “produces what appears to be an incorrect result.”

Have I tried it? No.  I have not because it is telling me that the url I tried 
to create is nothing like the URL I tried to create.

Spending some time looking at it this morning and testing against the working 
string, it is apparent that the /api gets stripped off the URL when using 
relativeToURL.  Look at this.

(lldb) po self.sharedData.webServices
home-qa.mrcooper.com/api
 
(lldb) po self.sharedData.webServicesURL
https://home-qa.mrcooper.com/api
 
(lldb) po [[NSURL URLWithString:[NSString stringWithFormat:@"%@%@%@", 
@"https://;, self.sharedData.webServices, @"/login"]] absoluteURL]
https://home-qa.mrcooper.com/api/login
 
(lldb) po [[NSURL URLWithString:@"/login" 
relativeToURL:self.sharedData.webServicesURL] absoluteURL]
https://home-qa.mrcooper.com/login
 
See how relativeToURL: strips off the /api text from the URL?
 

So strange why they thought it a good idea to output the description and 
debugDescription that way AND strip off part of the URL.

Argh.  Thanks for the second (and third) set of eyes.
Alex Zavatone


Sent from my iPad
 
> On Feb 22, 2019, at 10:48 AM, Jens Alfke  wrote:
> 
> 
> 
>> On Feb 22, 2019, at 8:39 AM, Alex Zavatone  wrote:
>> 
>> self.loginURL = [NSURL URLWithString:@"/login" 
>> relativeToURL:self.sharedData.webServicesURL]; // // WHY does this not work? 
>> It does "/login -- https://qa-home.mrcooper.com/api;
> 
> Because NSURL’s .description property has a stupid way of printing a relative 
> URL.
> 
> The actual URL is correct, as you’ll see if you do something like `po 
> self.loginURL.absoluteString`. It should return ` 
> https://qa-home.mrcooper.com/login`.
> 
> Moral of the story: Always use .absoluteString to convert an NSURL to a 
> string, never .description or something that calls it implicitly.
> 
> —Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: My eyes are failing me.

[Jens Alfke]

> On Feb 22, 2019, at 8:39 AM, Alex Zavatone  wrote:
> 
> self.loginURL = [NSURL URLWithString:@"/login" 
> relativeToURL:self.sharedData.webServicesURL]; // // WHY does this not work? 
> It does "/login -- https://qa-home.mrcooper.com/api 
> "

Because NSURL’s .description property has a stupid way of printing a relative 
URL.

The actual URL is correct, as you’ll see if you do something like `po 
self.loginURL.absoluteString`. It should return ` 
https://qa-home.mrcooper.com/login` .

Moral of the story: Always use .absoluteString to convert an NSURL to a string, 
never .description or something that calls it implicitly.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: My eyes are failing me.

[Ken Thomases]

On Feb 22, 2019, at 10:39 AM, Alex Zavatone  wrote:
> 
> I was adding some basic networking code to a simple case test and decided to 
> try out NSURL URLWithString: relativeToURL:
> 
> As can be seen in the output below, it attempts to be doing the opposite of 
> what is expected.  All I am trying to do is append a string to an NSURL and 
> get back an NSURL.   
> 
> Am I making some monumentally obvious mistake in the code below? Because I 
> can’t see it.
> 
> FYI, Xcode 10.1, iOS 12.1
> 
> 
> self.loginURL = [NSURL URLWithString:@"/login" 
> relativeToURL:self.sharedData.webServicesURL]; // // WHY does this not work? 
> It does "/login -- https://qa-home.mrcooper.com/api;

In what way, other than its debug description, does it "not work"?  Have you 
tried actually using it?

> (lldb) po self.sharedData.webServicesURL
> https://qa-home.mrcooper.com/api
> 
> (lldb) po  [NSURL URLWithString:@"/login" 
> relativeToURL:self.sharedData.webServicesURL]
> /login -- https://qa-home.mrcooper.com/api
> 
> (lldb) po self.sharedData.webServicesURL.absoluteString
> https://qa-home.mrcooper.com/api 
Remember that "po" just asks the object to describe itself.  NSURL objects 
which were constructed relative to another URL describe themselves that way, 
with the relative part and then the relative-to URL.  That self-description 
doesn't affect how it works.  What you didn't do was:

po [[NSURL URLWithString:@"/login" 
relativeToURL:self.sharedData.webServicesURL] absoluteString]

That would have shown the URL you expected.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com