[asterisk-dev] Asterisk 14 - Remote URI Playback

[Johan Wilfer]

Den 2014-11-06 21:40, Matthew Jordan skrev:
> On Wed, Nov 5, 2014 at 3:58 AM, Johan Wilfer <lists at jttech.se> 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