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

Caching #177

Closed
wants to merge 41 commits into from
Closed

Caching #177

wants to merge 41 commits into from

Conversation

pezra
Copy link
Contributor

@pezra pezra commented Feb 3, 2015

Implementation of HTTP caching using rake-cache's persistance layer. Based on @Asmod4n's initial pass (https://github.com/Asmod4n/http/compare/caching) but much has changed. :) Addresses issue #77.

@ixti
Copy link
Member

ixti commented Feb 4, 2015

Huge! Some cleanups and refactorings and would be good to go. :D

@@ -23,7 +23,7 @@ end
require "yardstick/rake/verify"
Yardstick::Rake::Verify.new do |verify|
verify.require_exact_threshold = false
verify.threshold = 58
verify.threshold = 58.1
Copy link
Member

Choose a reason for hiding this comment

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

does this not support >= 50 or something like that?

Copy link
Member

Choose a reason for hiding this comment

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

It is. And verify.threshold = 58.1 in conjunction with verify.require_exact_threshold = false (above) means >= 58.1. We bump it up to try to enforce ourselves to "keep moving forward" to the 100% API documentation coverage :D

@tarcieri
Copy link
Member

tarcieri commented Feb 4, 2015

Yeah, I'll second huge... looks interesting though.

@pezra
Copy link
Contributor Author

pezra commented Feb 4, 2015

It is pretty big but mostly self contained. Hopefully that will make it easier to understand. I'm fixing many of the RuboCop atm. (Pretty sure it hates me as much as i despise it.:) ) Those issues are why the build is broken (the tests already pass) so it should go green with that commit.

I'll integrate any feed back asap so comment away.

@Asmod4n
Copy link
Contributor

Asmod4n commented Feb 4, 2015

\o/ I would replace the locking InMemoryStore with a https://github.com/ruby-concurrency/thread_safe collection, and maybe constantize the most use Strings for a performance boost.

Thanks for taking this over :)

@pezra
Copy link
Contributor Author

pezra commented Feb 4, 2015

@Asmod4n, no problem. Thanks for getting it started.

@@ -59,3 +59,6 @@ Style/StringLiterals:

Style/TrivialAccessors:
Enabled: false

Style/AlignParameters:
Enabled: false
Copy link
Member

Choose a reason for hiding this comment

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

Please do not disable this cop.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. I think this rule encourages harder to read code but it is your house. :)

Copy link
Member

Choose a reason for hiding this comment

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

It encourages consistency of alignment 😜

@ixti
Copy link
Member

ixti commented Feb 4, 2015

@pezra Can you please rename:

HTTP::Cache::RequestWithCacheBehavior -> HTTP::Request::Cached
HTTP::Cache::ResponseWithCacheBehavior -> HTTP::Response::Cached

HTTP::Cache::CacheControl -> HTTP::Cache::Control

Also, IMO CacheControl should be named Cache::Headers actually and should be a decorator/facade of HTTP::Headers instead, thus initializer will accept headers structure directly. I'll try to provide my proposal as commit. :))

@pezra
Copy link
Contributor Author

pezra commented Mar 4, 2015

@tarcieri, thanks for reviewing!

I change the file loading behavior so that rack, etc is not required until caching is enabled. For example, HTTP.with_cache(metastore: ...) causes the caching code, rack-cache, etc to be loaded. That deviates a little from your suggestion but seems to accomplish the goal while being a little easier on user.

@tarcieri
Copy link
Member

tarcieri commented Mar 4, 2015

Seems good, thanks! Will wait to hear what @ixti says

@@ -26,6 +26,7 @@ group :test do
gem "rspec-its"
gem "rubocop"
gem "yardstick"
gem "fakefs", :require => "fakefs/safe"
Copy link
Member

Choose a reason for hiding this comment

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

Seems like not used (and thus useless) dependency

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It was left over from a failed approach to testing the caching stuff. Removed.

@ixti
Copy link
Member

ixti commented Mar 9, 2015

Please, move let statements in specs to the top of blocks they belong to.

@pezra
Copy link
Contributor Author

pezra commented Mar 9, 2015

Please, move let statements in specs to the top of blocks they belong to.

Where you think they belong. :) I prefer to put the important part of the tests front and center and leave the less interesting support structures below the fold.

It's your code base, though, so i'll do that.

@ixti
Copy link
Member

ixti commented Mar 9, 2015

@pezra I mean following:

describe :a do
  let(:b) { 1 }
  describe :c do
    let(:d) { 2 }
  end
end

:b belongs to block :a.
:c belongs to :a (declared inside :a) so it has access to :b as well.
:d belongs to block :c.

I just prefer to read specs from top to the bottom. And it's a bit inconvenient to me to scroll down to understand "initial" data. :D

@ixti
Copy link
Member

ixti commented Mar 9, 2015

In other words. let goes first things in the block. Then goes subject if it is needed. Then before/after hooks. Then it examples. Then nested context/describes.

@pezra
Copy link
Contributor Author

pezra commented Mar 9, 2015

I just prefer to read specs from top to the bottom.

Of course. However, if a spec's purpose cannot be understood without referring to the let definitions i consider that a naming failure. Such failures are, imo, better fixed by finding highly indicative names rather than rearranging things so that the glossary comes first.

@pezra
Copy link
Contributor Author

pezra commented Mar 9, 2015

@ixti, i think all the issues you noted are sorted out now.

@@ -80,6 +82,8 @@ def initialize(verb, uri, headers = {}, proxy = {}, body = nil, version = "1.1")

@headers["Host"] ||= default_host
@headers["User-Agent"] ||= USER_AGENT
now = Time.now
@headers["Date"] = now.httpdate
Copy link
Member

Choose a reason for hiding this comment

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

Clients SHOULD only send a Date header field in messages that include an entity-body, as in the case of the PUT and POST requests, and even then it is optional. A client without a clock MUST NOT send a Date header field in a request.

The HTTP-date sent in a Date header SHOULD NOT represent a date and time subsequent to the generation of the message. It SHOULD represent the best available approximation of the date and time of message generation, unless the implementation has no means of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the entity is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic value.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18

So, looks like this should go to Request::Caching instead. And also we MUST not override headers if they were explicitly given by user.

Copy link
Member

Choose a reason for hiding this comment

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

Actually I'm not sure if this still needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch.

@ixti
Copy link
Member

ixti commented Mar 16, 2015

I have merged PR into master. Thanks!

@ixti ixti closed this Mar 16, 2015
@pezra
Copy link
Contributor Author

pezra commented Mar 16, 2015

Yay! Thanks @ixti.

tarcieri added a commit that referenced this pull request Jul 22, 2015
Reverts support for client-side caching using rack-cache, added here:

#177

There have been ongoing maintenance problems with this code
(e.g. fd04847) and it's also implicated in
breakages and performance problems on JRuby 9000:

#239
tarcieri added a commit that referenced this pull request Jul 22, 2015
@tarcieri tarcieri mentioned this pull request May 28, 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.

4 participants