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

Introduce `auto-to-strict` config setting on client- and server-side #117

Open
ktoso opened this Issue Sep 8, 2016 · 6 comments

Comments

Projects
None yet
3 participants
@ktoso
Copy link
Member

ktoso commented Sep 8, 2016

Issue by sirthias
Wednesday Sep 23, 2015 at 10:27 GMT
Originally opened as akka/akka#18540


Currently the core layer only strictifies incoming message entities if the response bytes are fully contained in the chunk of bytes that have currently been read from the receive buffer.
Since this is non-deterministic the user always has the responsibility for "draining" the entity bytes from the connection in order to free it up for subsequent messages.

The proposal is to introduce a new config setting called akka.http.parsing.auto-to-strict which increases user convenience for the standard case (when the entity is "small") and at the same time removes all non-determinism.

Possible values for the setting:

  • off
    The parser never creates strict entities, even if the bytes are "already there".
  • on
    The parser always strictifies unchunked entities. Boundedness is achieved solely via the max-content-length setting.
  • <int value>
    The content-length threshold up to which the parser automatically strictifies the entity.

@ktoso ktoso added this to the 2.4.11 milestone Sep 8, 2016

@ktoso ktoso added t:http labels Sep 8, 2016

@ktoso

This comment has been minimized.

Copy link
Member Author

ktoso commented Sep 8, 2016

Comment by jrudolph
Thursday Sep 24, 2015 at 08:59 GMT


This ties in with the proposals in (17694) #105 and should probably approached "holistically".

In general, several parsing modes are possible that would determine what kind of entities the user can expect when receiving an HttpMessage:

  • the current behavior, with entity types very closely fitting what comes in on the wire
    • one disadvantage is the somewhat unnatural and non-deterministic distinction between Strict and Default
    • each chunk is currently aggregated before it is dispatched
  • only Strict messages (this ticket, I like the proposed configuration options)
  • only streamed messages (either with or without content-length available), see (17694) #105
    • Chunked entities would be auto-converted to Default-ones to prevent having to collect full chunks
@ktoso

This comment has been minimized.

Copy link
Member Author

ktoso commented Sep 8, 2016

Comment by ktoso
Thursday Sep 24, 2015 at 12:03 GMT


Thanks a lot for reporting this and the insights, makes a lot of sense, marking triaged for now.

@ktoso

This comment has been minimized.

Copy link
Member Author

ktoso commented Sep 8, 2016

Comment by ktoso
Thursday May 19, 2016 at 01:15 GMT


Triaged. Also, one of the things which might impact our behaviour in raw throughput benchmarks I think.

@ktoso ktoso added 1 - triaged and removed t:http labels Sep 8, 2016

@ktoso ktoso removed this from the 2.4.11 milestone Sep 12, 2016

@stefanasseg

This comment has been minimized.

Copy link

stefanasseg commented Nov 1, 2016

Any progress on this?

@ktoso

This comment has been minimized.

Copy link
Member Author

ktoso commented Nov 2, 2016

No comments / markers means no progress, as simple as that.
We have more urgent things to ship on our plates sadly right now - finishing 10.0 stable as well as HTTP/2 work.

We'd be thrilled to see a community contribution, e.g. from yourself since you seem interested, of this feature.
Happy to provide guidance how to start working on it but won't have the time to do so myself in the next weeks.

@ktoso

This comment has been minimized.

Copy link
Member Author

ktoso commented Nov 2, 2016

Related ticket #105

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.