Re: My eyes are failing me.

> 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

Re: My eyes are failing me.

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

Re: My eyes are failing me.

> 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

Re: My eyes are failing me.

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

Re: My eyes are failing me.

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

Re: My eyes are failing me.

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

Re: My eyes are failing me.

> 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

Re: My eyes are failing me.

> 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" >

Re: My eyes are failing me.

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]

Re: My eyes are failing me.

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

Re: My eyes are failing me.

> 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

Re: My eyes are failing me.

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

My eyes are failing me.

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.