baseURL #72

Closed
JonB opened this Issue Oct 9, 2011 · 17 comments

Comments

Projects
None yet
6 participants
@JonB

JonB commented Oct 9, 2011

If using a baseURL such as http://api.webapp.com/2.0/ when coming to make a request the 2.0/ part of the baseURL gets stripped.

Is this by design?

@jparise

This comment has been minimized.

Show comment Hide comment
@jparise

jparise Oct 10, 2011

Contributor

Does setting the baseURL to http://api.webapp.com/2.0 (no trailing slash) help? I believe that might be a side effect of NSURL's baseURL handling.

Contributor

jparise commented Oct 10, 2011

Does setting the baseURL to http://api.webapp.com/2.0 (no trailing slash) help? I believe that might be a side effect of NSURL's baseURL handling.

@JonB

This comment has been minimized.

Show comment Hide comment
@JonB

JonB Oct 10, 2011

It does it both with and without the trailing /

I've narrowed this down to the 'change' happening on line 172. If this is intentional, let me know and I will adjust for my needs.

Before
Before

After
After

JonB commented Oct 10, 2011

It does it both with and without the trailing /

I've narrowed this down to the 'change' happening on line 172. If this is intentional, let me know and I will adjust for my needs.

Before
Before

After
After

mattt added a commit that referenced this issue Oct 10, 2011

@mattt

This comment has been minimized.

Show comment Hide comment
@mattt

mattt Oct 10, 2011

Contributor

Good call. I guess I was being accidentally prescriptivist in my REST-ful ways with this implementation. If I change it to be [self.baseURL URLByAppendingPathComponent:path];, it should fit existing behavior, but also work for the case you described (nice Xcode color scheme, by the way). I fixed this on the experimental 0.7 branch (62596c2), which will be officially released early this week.

Thanks!

Contributor

mattt commented Oct 10, 2011

Good call. I guess I was being accidentally prescriptivist in my REST-ful ways with this implementation. If I change it to be [self.baseURL URLByAppendingPathComponent:path];, it should fit existing behavior, but also work for the case you described (nice Xcode color scheme, by the way). I fixed this on the experimental 0.7 branch (62596c2), which will be officially released early this week.

Thanks!

@mattt mattt closed this Oct 10, 2011

@dickbrouwer

This comment has been minimized.

Show comment Hide comment
@dickbrouwer

dickbrouwer Oct 12, 2011

Contributor

Hmm, unfortunately this fix introduces another issue: URLs ending in a trailing slash don't work anymore (an additional trailing slash is appended).

Contributor

dickbrouwer commented Oct 12, 2011

Hmm, unfortunately this fix introduces another issue: URLs ending in a trailing slash don't work anymore (an additional trailing slash is appended).

@mattt

This comment has been minimized.

Show comment Hide comment
@mattt

mattt Oct 12, 2011

Contributor

Which URL are you talking about?

Per Apple's docs: "If the original URL does not end with a forward slash and pathComponent does not begin with a forward slash, a forward slash is inserted between the two parts of the returned URL, unless the original URL is the empty string."

Is that not the case?

Contributor

mattt commented Oct 12, 2011

Which URL are you talking about?

Per Apple's docs: "If the original URL does not end with a forward slash and pathComponent does not begin with a forward slash, a forward slash is inserted between the two parts of the returned URL, unless the original URL is the empty string."

Is that not the case?

@dickbrouwer

This comment has been minimized.

Show comment Hide comment
@dickbrouwer

dickbrouwer Oct 12, 2011

Contributor

Right now if I supply: "/api/users/", it is transformed into: "/api/users//"
"/api/users" stays "/api/users". I'm not able to call "/api/users/".

btw, you can reproduce this with: [client postPath:@"api/v1/users/" parameters:params success:^(id object) {} failure:^(NSHTTPURLResponse *response, NSError *error){}]

Contributor

dickbrouwer commented Oct 12, 2011

Right now if I supply: "/api/users/", it is transformed into: "/api/users//"
"/api/users" stays "/api/users". I'm not able to call "/api/users/".

btw, you can reproduce this with: [client postPath:@"api/v1/users/" parameters:params success:^(id object) {} failure:^(NSHTTPURLResponse *response, NSError *error){}]

@mattt

This comment has been minimized.

Show comment Hide comment
@mattt

mattt Oct 13, 2011

Contributor

That's awfully prescriptivist of Apple, isn't it? Huh, seeing as how this behavior is shared for both NSString and NSURL methods concerned with paths (since they're for file paths, and not string representations of web URLs), I'll need to write my own method for this... bummer.

Contributor

mattt commented Oct 13, 2011

That's awfully prescriptivist of Apple, isn't it? Huh, seeing as how this behavior is shared for both NSString and NSURL methods concerned with paths (since they're for file paths, and not string representations of web URLs), I'll need to write my own method for this... bummer.

@dickbrouwer

This comment has been minimized.

Show comment Hide comment
@dickbrouwer

dickbrouwer Oct 13, 2011

Contributor

Yes - I think it is a problem/ambiguity with RFC 2396. If the url points to a directory it should have a trailing slash, if it's a file it shouldn't (this distinction doesn't really apply anymore to modern webservers of course). I also doubt that you want to deal with Apple's 2 distinct methods for handling these:

– URLByAppendingPathComponent:
– URLByAppendingPathComponent:isDirectory:

Contributor

dickbrouwer commented Oct 13, 2011

Yes - I think it is a problem/ambiguity with RFC 2396. If the url points to a directory it should have a trailing slash, if it's a file it shouldn't (this distinction doesn't really apply anymore to modern webservers of course). I also doubt that you want to deal with Apple's 2 distinct methods for handling these:

– URLByAppendingPathComponent:
– URLByAppendingPathComponent:isDirectory:

mattt added a commit that referenced this issue Oct 13, 2011

@mattt

This comment has been minimized.

Show comment Hide comment
@mattt

mattt Oct 13, 2011

Contributor

NSURL manipulation, to any extent, has always given me the jibblies—just no telling what's going to happen most times.

I think 68ef25c fixes that trailing slash problem, yeah?

Contributor

mattt commented Oct 13, 2011

NSURL manipulation, to any extent, has always given me the jibblies—just no telling what's going to happen most times.

I think 68ef25c fixes that trailing slash problem, yeah?

@dickbrouwer

This comment has been minimized.

Show comment Hide comment
@dickbrouwer

dickbrouwer Oct 17, 2011

Contributor

Sorry, I was out for a few days. Yes, this seems to work perfectly. Thanks for fixing it!

Contributor

dickbrouwer commented Oct 17, 2011

Sorry, I was out for a few days. Yes, this seems to work perfectly. Thanks for fixing it!

@schubter

This comment has been minimized.

Show comment Hide comment
@schubter

schubter Oct 17, 2011

it makes the link now http:/host/path -- just one slash between the protocol and the host, it however correctly opens the url.
i was implementing a oAuth 1.0a consumer and ran into the issue when constructing the signature when using self.baseURL in the class extending AFHTTPClient.

just a heads up

it makes the link now http:/host/path -- just one slash between the protocol and the host, it however correctly opens the url.
i was implementing a oAuth 1.0a consumer and ran into the issue when constructing the signature when using self.baseURL in the class extending AFHTTPClient.

just a heads up

@mattt

This comment has been minimized.

Show comment Hide comment
@mattt

mattt Oct 17, 2011

Contributor

@schubter Is that with the changes from 68ef25c? I'm seriously about to punch NSURL in its subclass.

Contributor

mattt commented Oct 17, 2011

@schubter Is that with the changes from 68ef25c? I'm seriously about to punch NSURL in its subclass.

@schubter

This comment has been minimized.

Show comment Hide comment
@schubter

schubter Oct 17, 2011

yes unfortunately it is

yes unfortunately it is

mattt added a commit that referenced this issue Oct 17, 2011

[Issue #72] More fixes to construction of URL from relative path, pre…
…venting scheme from incorrectly changing :// to :/
@mattt

This comment has been minimized.

Show comment Hide comment
@mattt

mattt Oct 17, 2011

Contributor

Alright, try 3040aaf. Does that fix it for you?

On 2011/10/17, at 14:27, Andreas Schubert wrote:

yes unfortunately it is

Reply to this email directly or view it on GitHub:
https://github.com/gowalla/AFNetworking/issues/72#issuecomment-2433532

Contributor

mattt commented Oct 17, 2011

Alright, try 3040aaf. Does that fix it for you?

On 2011/10/17, at 14:27, Andreas Schubert wrote:

yes unfortunately it is

Reply to this email directly or view it on GitHub:
https://github.com/gowalla/AFNetworking/issues/72#issuecomment-2433532

@schubter

This comment has been minimized.

Show comment Hide comment
@schubter

schubter Oct 17, 2011

yes, perfect. thanks

yes, perfect. thanks

@JonB

This comment has been minimized.

Show comment Hide comment
@JonB

JonB Oct 30, 2011

superb, thanks.

JonB commented Oct 30, 2011

superb, thanks.

egrim pushed a commit to egrim/AFNetworking that referenced this issue Sep 18, 2012

egrim pushed a commit to egrim/AFNetworking that referenced this issue Sep 18, 2012

egrim pushed a commit to egrim/AFNetworking that referenced this issue Sep 18, 2012

[Issue #72] More fixes to construction of URL from relative path, pre…
…venting scheme from incorrectly changing :// to :/
@priteshshah1983

This comment has been minimized.

Show comment Hide comment
@priteshshah1983

priteshshah1983 Dec 19, 2012

The same issue exists in AFHTTPClient.m on line 419

url = [NSURL URLWithString:[[url absoluteString] stringByAppendingFormat:[path rangeOfString:@"?"].location == NSNotFound ? @"?%@" : @"&%@", AFQueryStringFromParametersWithEncoding(parameters, self.stringEncoding)]];

The [url absoluteString] strips off the /2.0/ part

The same issue exists in AFHTTPClient.m on line 419

url = [NSURL URLWithString:[[url absoluteString] stringByAppendingFormat:[path rangeOfString:@"?"].location == NSNotFound ? @"?%@" : @"&%@", AFQueryStringFromParametersWithEncoding(parameters, self.stringEncoding)]];

The [url absoluteString] strips off the /2.0/ part

greghe pushed a commit to skillz/AFNetworking that referenced this issue Sep 3, 2015

greghe pushed a commit to skillz/AFNetworking that referenced this issue Sep 3, 2015

greghe pushed a commit to skillz/AFNetworking that referenced this issue Sep 3, 2015

[Issue #72] More fixes to construction of URL from relative path, pre…
…venting scheme from incorrectly changing :// to :/
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment