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 <puns...@mac.com> 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 <z...@mac.com> 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 <z...@mac.com> 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 <j...@mooseyard.com> wrote:
>>>>
>>>>
>>>>
>>>>> On Feb 22, 2019, at 8:39 AM, Alex Zavatone <z...@mac.com> 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
