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

Antony Polukhin's review #26

Open
2 of 10 tasks
vinipsmaker opened this issue Jan 4, 2016 · 2 comments
Open
2 of 10 tasks

Antony Polukhin's review #26

vinipsmaker opened this issue Jan 4, 2016 · 2 comments

Comments

@vinipsmaker
Copy link
Member

vinipsmaker commented Jan 4, 2016

Memory management

  • boost::http::basic_socket should be able to receive some parser_traits. Such parser_traits should allow us to limit maximum HTTP header key and value sizes and it should also allow to limit number of headers as well as maximum body size. The point is that should be possible to avoid reallocations and leave memory management for the user. Other useful options are strict/liberal parser, predicate to decide whether header should be stored (blacklist wouldn't work)...
  • Expanding on the above item, there should be a portable interface among sockets to dictate maximum size for some HTTP elements. basic_socket should implement it. Other backends may not (On the non-hacky front).
  • Further tune Message concept to allow an implementation that will drop info at insertion time instead relying on C++11's container concepts. Text should be in the lines of something like "this operation potentially insert an element...". (How could a user provide a message concept that satifies the SequenceContainer for the body avoid memory allocations?...).
  • Fix vector capacity tuning.
  • Remove all (implicitly) allocating code (e.g. last_header).

Others

  • Provide a HTTP parser. This way, user can benefit even if he won't use Asio.
  • Provide algorithm that will create a HTTP raw stream (represented as a string) from a HTTP message. Also provide a "literal message" of some sort that is created using literal strings and return a const value of an unspecified type that models the Message concept.
  • Implement HTTP/2.0
  • Friendlier interface. It should be addressed with a request router and better documentation that makes use of such router.
  • Provide algorithms to remove boilerplate on reading messages (http::completions::full(message_) is a functor).

WON'T FIX

@vinipsmaker
Copy link
Member Author

Remove all (implicitly) allocating code (e.g. last_header).

This item made lot of progress on the read path of Socket.

@vinipsmaker
Copy link
Member Author

http::stream

It could work on client-side maybe: http://think-async.com/Urdl/doc/html/urdl/reference/core/read_stream.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant