Max response size (Response.binary)

[passwone]

Hello, nice library !
I'm looking for a way to reject response when his content size exceed a limit.
Unfortunately, JdkRequest and ApacheRequest already "consume" all the content and place it into an array of bytes. Did you already have this kind of needs ?

[amihaiemil]

@passwone I had a quick look now - there is nothing "clean" you can do since JdkRequest uses it's own private Wire which always extracts the body content. Clearly some design changes would need to be done in the library to offer the flexibility you're mentioning.

Until that will be done (if this ticket is approved by the architect), I think you could use a fake Wire decorator.
It would be fake, in that inside your send(...) method you won't call this.origin.send(...). So basically, copy the private Wire from inside JdkRequest, but remove/alter the content consuming logic to fit your needs and hand it to your request using the through(...) method - see Javadoc of Wire.

It's dirty, I know, but quick way for you to integrate your logic with the library :)

[passwone]

@amihaiemil thanks for your response. I rewrote a new Wire based on JdkRequest's Wire. But, as you said, it's not quite elegant :)
I have no "real" idea of changes that can be made in the library to handle this "feature". I think that like TrustedWire (use of global variable trick and thread lock are equally dirty to me), something is missing in the Wire definition. If one of the architect could explain the way the improvement can be done, I would be happy to know it ;)

[amihaiemil]

@passwone Yes, it would be a fun thing to implement. Most likely using decorators of Request and/or Response, I didn't analyze in such depth.

A big issue, however, would be to keep backwards compatibility. Anything can be done, but I don't think we want existing users to start getting red errors and have to rewrite the code when they increment the lib's version in pom.xml :D

Anyway, a PM will ping the architect to dispatch this soon and he will decide how we should proceed :)

[amihaiemil]

@passwone please, just stay on the line, don't deactivate notifications from this issue - if it's approved, you'll have to close it in the end; it's how we work :)

[passwone]

Most likely using decorators of Request and/or Response

@amihaiemil Exactly! It's the way to go ;)
I let the issue opened hoping that it will create some talks about the best way to go to create more elegant OOP version of this library !

[dmarkov]

@yegor256 please dispatch this issue

[amihaiemil]

@yegor256 can I have this?