Skip to content
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

ESP8266HTTPClient: allow getString() more than once #5091

Merged
merged 1 commit into from
Sep 9, 2018

Conversation

yoursunny
Copy link
Contributor

fixes #4951

@yoursunny
Copy link
Contributor Author

I choose to store unique_ptr<StreamString> rather than String on the HTTPClient class, so that getString does not need to copy StreamString into String.
Program size of #4951 (comment) sketch increases from 268400 bytes to 268496 bytes due to this change.

Copy link
Collaborator

@devyte devyte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no way to clear the contents, i.e.: once _payload is set, the mem is held forever, or until the next string arrives and it is set again.
I don't see an easy way to fix that.
My guess is that what should happen is that the getString() implementation shouldn't be based on writeToStream(), because streams inherently consume input, but I don't know what the solution should look like.

@yoursunny
Copy link
Contributor Author

There is no way to clear the contents

_payload is deallocated by clear(), which is invoked when the client is begin'ed next time.
One potential solution is making clear() public, so that the user can decide when to free the payload String.

the getString() implementation shouldn't be based on writeToStream()

The entire payload has to be buffered somewhere in memory. If getString() does not use writeToStream, it still doesn't solve the memory deallocation problem.

@devyte
Copy link
Collaborator

devyte commented Sep 4, 2018

Agreed on making clear public, sounds like a good enough compromise.

Edit: On second thought, it's not a good idea to expose clear(), it will be confusing to have both an end() and a clear(). Instead, I think end() should call clear().

@yoursunny
Copy link
Contributor Author

Intuitively (and according to Arduino’s docs), the sketch invokes end() when they are done with the response. Then I find writeToStream calls end(). Since getString() uses writeToStream, calling clear() in end() would delete _payload immediately.

How about:

  • Move the TCP disconnect stuff from end() to a protected disconnect() function.
  • clear() remains protected and unchanged.
  • end() calls disconnect(); clear();.
  • writeToStream calls disconnect() at last.

@devyte
Copy link
Collaborator

devyte commented Sep 5, 2018

Refactoring basics :) please go ahead!

@yoursunny
Copy link
Contributor Author

"end = disconnect + clear" design has been implemented.

@devyte devyte merged commit bbaea5a into esp8266:master Sep 9, 2018
@yoursunny yoursunny deleted the 4951 branch September 9, 2018 03:44
d-a-v pushed a commit to d-a-v/Arduino that referenced this pull request Sep 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

HTTPClient.getString() returns payload on first call only and returns empty after
2 participants