Skip to content

Optionally enable caching of any request method #24

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.

Sign up for GitHub

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

Merged
merged 16 commits into from
Feb 20, 2017
Merged

Optionally enable caching of any request method #24

Changes from 1 commit
Commits
Show all changes
16 commits
Select commit Hold shift + click to select a range
52b1777
Enable caching of POST requests when requested
tuupola Feb 10, 2017
e0c1c0e
Make StyleCI happy
tuupola Feb 10, 2017
0a3b7c8
PSR-2 and short array syntax
tuupola Feb 11, 2017
8151701
Allow any valid request method as defined by RFC7230
tuupola Feb 13, 2017
baf4fbd
Include request body in cache key calculation
tuupola Feb 13, 2017
8d9d48c
Make StyleCI happy
tuupola Feb 13, 2017
5b21d4b
PHP 5.4 does not have ::class
tuupola Feb 13, 2017
cfa6135
Mention RFC7230 which defines valid request methods
tuupola Feb 14, 2017
8d8f8e9
Add new methods option to docblock
tuupola Feb 15, 2017
fbc1dc7
Request methods are case sensitive
tuupola Feb 15, 2017
e94b74a
Do not allow lowercase request methods
tuupola Feb 17, 2017
65d819d
Add delimiter between uri and body
tuupola Feb 17, 2017
10da16c
Remove unneeded use statement
tuupola Feb 17, 2017
9703885
Maintain cache key bc with v1.2.0
tuupola Feb 19, 2017
490da8b
Make StyleCI happy
tuupola Feb 19, 2017
727cbf0
Make StyleCI happy
tuupola Feb 19, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Mention RFC7230 which defines valid request methods
  • Loading branch information
@tuupola
tuupola committed Feb 14, 2017
commit cfa6135b89477947a9eac2fd69daf0ab09b6dae7
1 change: 1 addition & 0 deletions src/CachePlugin.php
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -281,6 +281,7 @@ private function configureOptions(OptionsResolver $resolver)
$resolver->setAllowedTypes('methods', 'array');
$resolver->setAllowedValues('hash_algo', hash_algos());
$resolver->setAllowedValues('methods', function ($value) {
/* Any VCHAR, except delimiters. RFC7230 sections 3.1.1 and 3.2.6 */
$matches = preg_grep('/[^[:alnum:]!#$%&\'*\/+\-.^_`|~]/', $value);
Copy link
Contributor

Choose a reason for hiding this comment

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

can you please add a comment here with the RFC number that defines this regular expression? just for future reference and to make it clear we did not come up with a random expression here.

Copy link
Contributor

Choose a reason for hiding this comment

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

i am horrible with regular expressions. is this forcing upper case? we should either force that or uppercase ourselves when processing the options. PSR-7 forces method to upper case. when you specify something lower case, it would never match.

the doc should explain that if you specify methods, you also need to specify GET if you still want those cached. and that you should do specific clients with different setup if you do soap and other stuff, to be sure only the right requests get cached...

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 does not force uppercase. [:alnum:] is alias for [0-9A-Za-z]. RFC2616 says method is case-insensitive so technically both get and GET should be valid but just different methods.

I have no strong feelings whether we should force uppercase or not. I think most of the time people probably use uppercase methods.

The regexp basically says is request method has any other characters than these the method is invalid.

Copy link
Member

Choose a reason for hiding this comment

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

This looks really complicated. Why not use [A-Z]+. That will also make sure you use upper values. Or am I too specific?

Copy link
Contributor Author

@tuupola tuupola Feb 16, 2017 •
edited
Loading

Choose a reason for hiding this comment

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

Unless I have misunderstood the specs request method can also contain lowercase letters. Valid request methods are described in RFC7230-3.1.1 which states it is a token. Token is defined in RFC7230-3.2.6 which says any visible USASCII character except delimiters "(),/:;<=>?@[\]{}.

Copy link
Member

Choose a reason for hiding this comment

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

Sorry, yes you are correct. (Reading the code and RFC more carefully...). I was wrong assuming that !#$%& etc should not be a part of the HTTP method.

HTTP methods are generally uppercase but PSR-7 specifies that case should not change. I think we are correct by running strtoupper(). This implementation will, however, always fail when using a lower case method in the configuration. I suggest changing the regex to fail directly if a lower-case method are used.

$matches = preg_grep('/[^[A-Z0-9]!#$%&\'*\/+\-.^_`|~]/', $value);

Copy link
Contributor

Choose a reason for hiding this comment

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

were do we strtoupper? i think we should leave the method unchanged, given how psr-7 is specified. as mentioned above, guzzle psr-7 request does not follow the SHOULD of the spec.


return empty($matches);
Expand Down