Den 2014-11-06 21:40, Matthew Jordan skrev:
On Wed, Nov 5, 2014 at 3:58 AM, Johan Wilfer <[email protected]> wrote:
Den 2014-11-05 08:45, BJ Weschke skrev:
As for the timestamps for deciding whether the local cache is dirty
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching
+1 This was my thought as well. We should stick to the HTTP standard, and
not have our own way of doing caching. In HTTP you have two models:
1. Timestamps (header "Expires")
2. E-tag for validation of the resource (header "If-None-Match").
Yup, E-tag is the way to go here. I'll punt on my suggestions that I
have on the wiki and re-write it to note that. Thanks!
Actually it's perfectly valid to mix these two methods. For example, we
could have both an E-tag and also an Expires-header one hour in the
future. That would mean that we can save the resource for one hour and
not check back. After one hour we will try to match the E-tag (that
would for example be based on the last modified time for the resource)
and if the E-tag has changed, re-download, and so on...
Anyway even if we only implement E-tag and skip the Expires-part of the
http specification this is a lot better than just doing some custom
asterisk timestamps.
But if we choose to not implement the full http specification regarding
caching this should be clearly noted so users are not surprised when
Asterisk doesn't honor the Expires & Cache headers.
Consider a sound resource named "stuff&things". This is technically a
valid resource name, so long as the "&" is URI encoded:
http://myserver.com/sounds/stuff%26things
If this was a query of some sorts, then my URI my look something like this:
http://myserver.com/sounds?media=yes&file=stuff%26things
This is where things break down in Asterisk dialplan (keeping in mind
that for ARI, you could put all of this into a JSON blob and not
care.) If we allowed '&' to be URI encoded in the Playback dialplan
application, this would look like:
same => n,Playback(http://myserver.com/sounds?media=yes%26file=stuff%26things)
And when Asterisk decoded the URI, it would turn this into:
http://myserver.com/sounds?media=yes&file=stuff&things
Which is very, very wrong.
Now, as BJ pointed out, we could escape things in *different* ways -
but I'm concerned that doing that would make things more complicated
and prone to breaking. As an API usage, it also makes it hard to know
how to pass data to Asterisk - the more custom things are, the harder
it is to know what to do. URI escaping is common; custom Asterisk-y
escaping is ... not.
All of this is a long way of saying that I'd be happy if we supported
'&' in a URI, but only at the expense of *not* supporting a URI
escaped '&' in a resource in that URI.
That's very reasonable. Thank you for the explanation!
One thought: If we would escape the "%" (evaluates to "%25"), wouldn't
this solve the problem? This would mean the user inputs:
same =>
n,Playback(http://myserver.com/sounds?media=yes%26file=stuff%2526things)
That asterisk will turn into:
same => n,Playback(http://myserver.com/sounds?media=yes&file=stuff%26things)
This could be explained as Asterisk doing url-decode once to allow for
special chars like &. But if the user would like to pass something
encoded he would be required to encode _twice_ as asterisk decodes once.
Maybe this is overly complicated. I'm more than happy with your
suggestion as it is.
--
Johan Wilfer
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
