kCFErrorDomainCFNetwork error 303

[Dustin S]

Hi,

I'm get the following error: "The operation couldn’t be completed.
(kCFErrorDomainCFNetwork error 303.)" This occurs during my attempt
to refresh existing user data. Essentially, I have an initial request
going out to my Rails backend as /users/(userID). I have this
functioning correctly and retrieve a substantial set of data to
hydrate a variety of relationships using the CoreData synchronization
of RestKit. My initial request, executes perfectly. However, I have
a "refresh" button that I'd like users to be able to tap to allow an
update. I'm requesting the exact same URL /users/(userID), but when
called from the refresh button, I ALWAYS get this 303 error. From
googling, it seems to have something to do with the inability to parse
the HTTP request and/or process the received response.

I'm a bit lost as to where to go here because I can see the request
actually get to my server and server log shows a 200 OK response. So,
it seems that after receiving the response, RestKit is failing to
process the same dataset upon a second request.

I'd post code, but some of it sensitive to my project and more
importantly, I'm not sure what part to post.

Any help is greatly appreciated.

Also, thanks for RestKit, other than this issue, it's a really
fantastic library that has saved me (and others) a lot of time.

- Dustin

[Mykhailo V Bevz]

Hey Dustin,

I'm getting exactly the same error right now. 

My situation is 

... Router set up

[router routeClass:[City class] toResourcePath:@"/regions/(region_id)/cities.json"];

... I set currentItem..

City* city = [City object];

city.region_id = [region id];

genericViewController.currentItem = city;

... a failing call follows ...

[[RKObjectManager sharedManager] getObject:currentItem delegate:self];

BR,

Mike

--
Best regards,
Mykhailo Bevz

[Kevin Lord]

I came across what is likely the same issue, and it was due to RestKit
providing an HTTP body when making a GET request. I ended up hacking
setRequestBody in RKRequest.m to look like the following, which is
probably not ideal. It did solve the issue for me though.

- (void)setRequestBody {
if ((_params) && (_method != RKRequestMethodGET)) {
// Prefer the use of a stream over a raw body
if ([_params respondsToSelector:@selector(HTTPBodyStream)]) {
[_URLRequest setHTTPBodyStream:[_params HTTPBodyStream]];
} else {
[_URLRequest setHTTPBody:[_params HTTPBody]];
}
}
}

-Kevin

[Dustin S]

This does the trick! Thanks so much! I've been trying to solve that
one for a couple of days now.

Blake/Jeremy, if you're looking in on this one, I'd recommend this
modified method as a patch. Or, alternatively, adding something to
RKClient that enables us to override this as a default. I don't
personally mind having to modify my version of the RestKit library,
but ideally, we wouldn't want to have to hack it like this.

- Dustin

[Jeremy Ellison]

Dustin,

Thanks for pointing out the issue. I believe this was merged into master over the weekend, so if you pull the latest bits it should work.

Cheers,

		Jeremy Ellison Two Toasters | Director of Development jer...@twotoasters.com (919) 827-1528

[Blake Watters]

I committed a patch to RKDyanmicRouter the other day that returns a nil serialization for GET requests. This should prevent the issue during use of getObject:, but allow you to set a body on GET requests if you manually construct the request (seems like its the path of least surprise).

		Blake Watters Two Toasters | CTO bl...@twotoasters.com (919) 926-8537

[Dustin S]

I updated to the master branch, but it turns out that this patch
doesn't make a difference for me. In all subsequent requests to the
same URL, it fails with the 303 network error. However, if I included
Kevin's patch on setRequestBody to exclude GET requests from the
process, everything works as expected.

I've done some searching on this and it seems that consensus on the
web says that while you can send an http body with a GET request, it's
never useful to do so. Servers which respect the HTTP ignore the body
on GET requests because it is reserved for the returned response. So,
while I agree with your approach of taking the path of least surprise,
I think it's still broken in this case. And I can't find a logical
reason that anyone would want to send a body on the GET request. (As
an aside, if you're working at the level anyway, it seems that RestKit
wouldn't be to your advantage anyhow. The whole point of using RK is
to simplify the messy process of dealing with URL connections and
such.)

So, for now, I'm back to Kevin's patch.

- Dustin

[Blake Watters]

Sold, I have merged the patch into 0.9

[Andre Medeiros]

Whoohooo!

Sent from my iPhone

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

[Kevin Lord]

Glad I could do the easy work with my < 1 line patch. :)

Thanks for getting it sorted out.  RestKit has been very helpful in my project!

-Kevin

Sent from my iPhone