-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repeated calls to client.get() fail. #2
Comments
I agree with a Stream implementation on this, but I am not the person who can do it. Please assign someone else with more familiarity with the guts of Stream. |
There's a HTTPSClient utility class in the AzureIoT library that we might be able to use. It currently is designed for keep alive connections and to bridge the HTTP layer needed by the Azure IoT SDK. As for implementing Stream maybe we could extend Stream and forward Stream API's to the Client passed in: int RestClient::available() {
return client.available();
}
int RestClient::read() {
return client.read();
}
int RestClient::peek() {
return client.peek();
}
void RestClient::flush() {
client.flush();
} It would be nice to stream the response header values, but some users might not care about those. |
Perhaps we could add a flag to ignore headers. Or just add a function to parse them out if you want them, and making ignoring them the default. |
We could make the library parse and ignore the headers if For example (this is loosely based on the HTTPSClient I link to earlier):
|
Kinda works. Could also maybe do something like readUntil(BODY), which would be readUntil("\n\n") and variants thereon. |
I like Sandeep's suggestion, although we might want to do |
I like that, Dave. |
This comment has been minimized.
This comment has been minimized.
@damellis's suggestion sounds good to me! |
I've been trying the SimpleGet example and get the below result. This is connecting to www.google.com, port 80, and calling:
client.get("/");
. It looks like the first call succeeds but gets only part of the page. Subsequent calls fail. Maybe we're running out of RAM?I think we may need to support a stream version of this API, where the RestClient class parses the headers but doesn't read the full body of the response. Instead, the user would call client.read() and other stream methods to process the response as needed.
The text was updated successfully, but these errors were encountered: