biasedbit / bbhttp Goto Github PK

Link is:

http://jasperblues.github.io/BBHotpotato/api/index.html

Should be your name there.

Also - you need to run the script to publish the docs or have a CI server do it.

I was reading this on Australian CocoaHeads and thought it might be a neat feature for BBHTTP:

Hi Gordon,

If you are using the AFNetworking library for communicating with your
web services, then you get the functionality to check for invalid
certificates out of the box, unless you #define
AFNETWORKING_ALLOW_INVALID_SSL_CERTIFICATES. Furthermore,
AFNetworking also has built in support for "certificate pinning" (see
Loukas' email). You can enable this by #define
AFNETWORKING_PIN_SSL_CERTIFICATES 1.

Hope this helps as well.

Regards,
Sadat

I want my response as NSData . . . reading the docs shows content type is 'id'. . .this is confusing.

[[BBHTTPRequest readResource:@"http://foo.bar/baz/1"] setup:^(id request) {
    // Prepare request...
} execute:^(BBHTTPResponse* response) {
    // Handle response...
} error:^(NSError* error) {
    // Handle error...
} finally:^{
    // Do after error OR success.
}];

... why is the setup block parameter typed to id? Is it a BBHTTPRequest?

Hi!

Nice lib! How about publishing the API docs on the github page? I use a script to get my build server to do it. Happy to share.

Hello,

I ran into a similar problem with NSURLConnection et al years ago, that 100-Continue support was non-existant.

Fairly recently I got round to filing a radar asking for this feature, and was surprised to receive a response that it is supported — since "at least" OS X 10.7 — simply by:

set the "Expect" header to "100-continue"

I'm curious, did you ever try this? Indeed, did you ever try dropping down to the CFHTTPStream level either?

. . . seems handy to have around.

Tried the following test case:

__block NSString* message;
[[BBHTTPRequest getResource:@"http:/www.google.com"] execute:^(BBHTTPResponse* r)
{
    NSLog(@"Finished: %u %@ -- received %u bytes of '%@'.", r.code, r.message, r.contentSize, r[@"Content-Type"]);
    message = r.message;
} error:^(NSError* e)
{
    NSLog(@"Request failed: %@", [e localizedDescription]);
}];

assertWillHappen(message != nil);

Expected it to pass, but got this response:

2013-03-18 14:10:02.684 otest[8577:707] *** Assertion failure in -[BBHTTPRequest setValue:forHeader:], /Users/jblues/Infraxis/mobile/iOS/Pods/BBHTTP/BBHTTP/BBHTTPRequest.m:269

value cannot be nil
Unknown.m:0: error: -[ClientTests test_some_http] : value cannot be nil

I'm thinking about exposing both CURLOPT_LOW_SPEED_LIMIT and CURLOPT_LOW_SPEED_TIME as a single property:

struct BBTransferRate {
    unsigned long bytesPerSecond;
    NSTimeInterval duration;
};
typedef struct BBTransferRate BBTransferRate;

BBTransferRate BBTransferRateMake(unsigned long bytesPerSecond, NSTimeInterval duration)
{
    BBTransferRate threshold;
    threshold.bytesPerSecond = bytesPerSecond;
    threshold.duration = duration;

    return threshold;
}

NSString* NSStringFromBBTransferRate(BBTransferRate transferRate)
{
    return [NSString stringWithFormat:@"%lu/s for %.0f seconds", transferRate.bytesPerSecond, transferRate.duration];
}

I think it's way more meaningful than two separate properties.

The property on BBHTTPRequest should probably be named requestTimeoutThreshold.

I like the direction this project is going. Is it possible to set POST key-value pairs from a dictionary? E.g for tweeting against the Twitter REST API.

If the libCurl is published in github (eg via build server) it world be easy to install this library via cocoapods

Hello,
I could not find your project support large file upload with resume support, could you pls implement that..?

I am sorry for this question, but I can't find where to put user and password in a request.
I tried in URL, but it won't work for me.

Show me how to get a plain string as well as Json and image. . .

I found what I was looking for. Maybe a link to docs for https://github.com/brunodecarvalho/BBHotpotato/blob/master/Classes/BBHTTPRequest%2BConvenience.h

. ... would make it even faster

Looks like cURL needs a rebuild. . I'll send a pull request soon.

This example:

[[BBHTTPRequest getResource:@"http://foo.bar/baz/1"] setup:^(id request) {
    // Prepare request...
} execute:^(BBHTTPResponse* response) {
    // Handle response...
} error:^(NSError* error) {
    // Handle error...
} finally:^{
    // Do after error OR success.
}];

... gives error, method does not exist... changing to readResource works.

The current BBHTTPResponse contract doesn't allow for multiple response headers. The property headers references a dictionary of NSString,NSString, so you can't set the same header several times.

For example, Set-Cookie might be present several times in the same response.

I'm used to Java, and there is this method in HttpServletResponse (the Java equivalent of BBHTTPResponse) :
http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#getHeaders(java.lang.String)

I have patched the lib in order to support that, and tried to keep backward compat.

I'll send a pull request ASAP.

Hi!

Could you in the readme say something about the advantages over say AFNetworking? I've read this part.

Well, unlike NSURLConnection and, consequently, any lib that relies on it, BBHTTP...

is strictly compliant with section 8.2.3 of RFC 2616, a.k.a. the misbeloved Expect: 100-Continue header;
can receive server error responses midway through upload — as opposed to continuing to pump data into socket eden, and eventually reporting connection timeout instead of the actual error response sent by the server.

And that's good. But I guess there is some other advantages and hidden gems maybe in the syntax and structure of BBHTTP over say AFNetworking?

Expose properties on BBHTTPRequest to modify CURLOPT_MAX_SEND_SPEED_LARGE and CURLOPT_MAX_RECV_SPEED_LARGE.

Get this:

!] git remote update

Fetching origin
fatal: https://github.com/brunodecarvalho/BBHotpotato/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?

error: Could not fetch origin

Instead of createResource/getResource, etc . . . how about using just get/post/put . .

I'm using the library for SOAPish type services and it certainly feels more natural in this case (I know exactly what I'm gonna get without reading docs). . . at the same time, in changing the method names I don't think it would hinder the experience when using the library for proper REST services. . . .what do you think?

Running Docs/Generate gives error

Error is:

ERROR: AppledocException: Path or file '/Users/jblues/Loud-and-Clear/BBHTTP/Docs/../Classes' doesn't exist!

. . also tried running Project/build.xml script that I submitted a while back. . . but found out the script only wants to be run from the root directory. . needs to be changed to run from /Project dir.

Can you comment on support for keep-alive HTTP connections on OS X using BBHTTP? From my limited testing it appears NSURLConnection on OS X opens and closes a connection on every call. I know libcurl supports keep alive so I was wondering if this ability is accessible in BBHTTP?

I was looking at using BBHTTP for FTP support as well as HTTP. For FTP support is looked like the main method that would need to be overridden was the executeContext:withCurlHandle: of BBHTTPExecutor class? I would only need directory listing and download capability for now.

Follow on from #16.

For me, composition always wins over inheritance. Chaining response handlers (responders?) would open up the doorway to some pretty cool stuff.

A good use case would be chaining a JSON parser to a responder which updates values on some model. The client wouldn't need to know about parsing JSON - it would essentially result in object mapping (which RestKit heavily relies on.)

Chaining diagram:

Request --> Selective Discarder --> JSON Parser --> Object Mapper

The client would then join the dots, fire a request, and that's it. SRP in action. Very similar to Apple's chain of responsibility, and to the Decorator design pattern.

Progress handling and error handling might also benefit from a similar pattern, e.g:

Request --> Selective Discarder --> Percentage Calculator --> Update Label (domain specific - deals with UI)

Or for errors:

Request --> Selective Discarder --> Error Localizer --> Alert Presenter (again, domain specific)

It would be necessary to have a concept of a compound response handler - one which forwards messages to multiple responders but appears as one object to the request - to handle responses differently:

Request --> Compound Handler --> Percentage Calculator --> Update Label
                            \--> Progress Bar Updater

I'm not sure how usable this would be to those uncomfortable with constructing a larger number of objects, or how difficult it would be implement. I have a feeling it's largely my preferred coding style leaking out, and that the best solution might be a compromise.