Add more options

[ahmdrz]

Hi ,
I want to add one more option, Expiration time , and there are two ways to implement it :

1. Expiration time using Date header.
2. Using until ... format in X-MINA-OPTIONS header.

In the first case , we can set a limit for each dumped file. For example , getting new response from target if the value of time.Now() - Date header is grater than EXPIRATION_TIME otherwise load from dumped file.

In the second case , Mina have to load dumped responses from corresponding requests that contain X-MINA-OPTIONS=until <DATE> header and Date header of dumped responses is grater than <DATE>.

To test Mina , I used it in inline app of Vajehyab so I need expiration time option.

What is your idea @siadat .

[siadat]

I'm all for expiration dates! I understand the second solution, could you explain the first one a bit more? How do we know if mina's cached version of a response is old enough to be expired?

[ahmdrz]

How do we know if mina's cached version of a response is old enough to be expired?

In both cases , we have Date header in dump files. The algorithm is similar to this :

1. Load dumped response.
2. If Date header is older than ... ( فلان 😄) load new response from target otherwise load dumped response.

In first case , we have a global const that tell Mina do not load dumped responses that their Date header is older than ... ( فلان 😄)

I think second case is more better than first case.

[siadat]

So, does that mean to avoid having to read the response file we would need to keep the value of the cached response's Date header in memory?

[ahmdrz]

No we don't need to save anything on memory , all of them are in disk.

But in first case , we can delete dump files.

[siadat]

time.Now() - Date

By reading this I'm guessing your are considering that Date values could be less than time.Now(). Could the value of the request's Date header be in the past? The Date is usually set to the date and time that the message was originated, so it's always almost equal to time.Now(), am I right?

If not, then please demonstrate your algorithm by a simple request that should be considered expired.

[ahmdrz]

Mr Siadat. Sorry for my bad english , Maybe I can't tell you what is in my mind.
I will show you by code.

[ahmdrz]

ahmdrz@1dc7105 and ahmdrz@b9d0333

Note: This is not completed

[siadat]

Cool @ahmdrz! The 2nd algorithm could be a bit difficult for clients to use, right? Because the clients will have to keep updating the "until" value once it is reached, otherwise mina will ignore cache for all subsequent requests that look like this:

X-MINA-OPTIONS: until ${an hour ago}

What do you think about supporting standard HTTP headers like Cache-Control?

[ahmdrz]

Your right 👌 I will try to implement Cache-Control header it's better than "until" format and it's standard header. Why I forgot this 😐😞 !! And yes , It's difficult to change "until" value , it's better to use something like "max-age" in seconds or preset values like "one hour ago". So , Do you agree with implementing Cache-Control instead of X-MINA-OPTIONS ? On Jan 16, 2018 23:49, Sina Siadat <notifications@github.com> wrote: Cool @ahmdrz<https://github.com/ahmdrz>! The 2nd algorithm could be a bit difficult for clients to use, right? Because the clients will have to keep updating the "until" value once it is reached, otherwise mina will ignore cache for all subsequent requests that look like this: X-MINA-OPTIONS: until ${an hour ago} What do you think about supporting standard HTTP headers like Cache-Control<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control>? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#8 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AQK5JME5uyd1eiB7_pZfESt0EcWgOM4zks5tLQRRgaJpZM4Resy->.

[siadat]

Lol it's okay. I think it would be a good idea to do a little bit of research about HTTP caching and proxy caching. Eg have a look at the http caching spec to see what is the recommended way to handle caches in proxies.