You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2013/09/11 03:25:18 UTC
Re: [5.4] Problems with the asset checksums and relative paths based
on them
This is a tricky one to handle.
It feels like we need yet another Asset URL path that works more like
modules: no checksum in the URL and no far-future expires header, but maybe
e-tags support.
Alternately, using the WYMeditor configuration, we could follow up on the
idea I had on the user mailing list: an alternate asset URL that sends a
proper redirect to the real asset. So /X/meta/wymeditor/foo.css would be
redirected to /assets.gz/meta/wymeditor/abc123/foo.css.
I'm not sure which approach is best; possibly having the non-optimized (no
checksum, no far-future expires header) Asset URL path; possible Asset or
Link in some way to make generating the non-optimized URL easier.
On Tue, Sep 10, 2013 at 4:07 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Hi!
>
> I'm writing an Tapestry integration for WYMeditor. It's main JavaScript
> file includes a lot of other ones based on relative paths.
>
> For example, the main file gets this URL: http://localhost:8080/asset.**
> gz/meta/wymeditor/883f64b8/**jquery.wymeditor.min.js<http://localhost:8080/asset.gz/meta/wymeditor/883f64b8/jquery.wymeditor.min.js>.
> In order to load the internationalized files, it attempts to load another
> .js file from (...)/883f64b8/jquery.**wymeditor.min.js. An
> AssetRequestHandler finds the file, but obviously the checksum doesn't
> match, so it returns a 404 error.
>
> WYMeditor allows the configuration of the folder URLs for its assets and
> other JS files, but then I'd need an classpath AssetRequestHandler that
> doesn't check for checksums and let it handle the assets needed by
> WYMeditor and configure it (WYMeditor) to use the paths it'll handle. I
> could write one, of course, but I'd just like to know whether there is some
> less brute-force option I'm overlooking.
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<us...@tapestry.apache.org>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
VS: [5.4] Problems with the asset checksums and relative paths based on them
Posted by Ville Virtanen <vi...@orientimport.fi>.
Would it be possible to calculate the checksum for certain folder (and subfolders) and let the developer decide if it is more appropriate to use per file or per directory checksum?
Ville
-----Alkuperäinen viesti-----
Lähettäjä: Thiago H de Paula Figueiredo [mailto:thiagohp@gmail.com]
Lähetetty: 12. syyskuuta 2013 14:55
Vastaanottaja: Tapestry development
Aihe: Re: [5.4] Problems with the asset checksums and relative paths based on them
On Wed, 11 Sep 2013 19:41:40 -0300, Barry Books <tr...@gmail.com> wrote:
> Perhaps a dumb question but why does the checksum need to match for
> Tapestry to return the file? The only problem I can think of is if the
> included file changes but the main file does not then the cached file
> might be used.
What do you mean by included file and main file?
> I would think that's unlikely to happen
Actually, browsers not getting updated JS, CSS and image files after they were changed in the server is quite common without some mechanism like that. In T5.1 projects, many times I've had to ask the testers to clear their caches because they were testing the fix and the problem was still appearing because of the browser cache.
I've actually fixed my problem by creating a request filter that checks for requests to files dynamically included by WYMeditor, find the original files in the classpath, generate a new Asset instance for them (which contains the right checksum) and redirects to it. Ugly, but fixes the problem. :)
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
VS: [5.4] Problems with the asset checksums and relative paths based on them
Posted by Ville Virtanen <vi...@orientimport.fi>.
The way I would like it to be is that the current functionality of Tap is the default and the per folder would be configurable, like (pseudocode)
@Contribute
public static void contributeFolderChecksum(conf) {
conf.add("classpath://org.dh.wymeditor.js");
}
and only that path and subfoldrs would get the per folder treatment. As said, I don't know how hard this would be implement, so I'm not sure if it is feasible.
If it would be feasible, then it comes down to the trade off between doing the redirects vs. downloading all the content in the given directory if something changes. For a library that updates seldom I think the folder approach is better, but for library that is massive and only small portions change frequently the redirects would be better.
As a developer I would like to be the one who makes the call, so perhaps I'll learn the source code first :D
Ville
-----Alkuperäinen viesti-----
Lähettäjä: Thiago H de Paula Figueiredo [mailto:thiagohp@gmail.com]
Lähetetty: 12. syyskuuta 2013 18:02
Vastaanottaja: Tapestry development
Aihe: Re: [5.4] Problems with the asset checksums and relative paths based on them
On Thu, 12 Sep 2013 09:43:40 -0300, Barry Books <tr...@gmail.com> wrote:
> If you have file a b and c. The page includes a which then includes b
> and c but in your case with a's checksum.
In my case, Tapestry can't know that file a included b and c, because a, which is JavaScript, dynamically included them in the page. It just knows b and c were requested with wrong checksums.
> If Tapestry just returned b and c with a's checksum everything would
> work fine. The only problem would be if you change b or c without
> changing a. I agree this could be a problem but if you are using a
> library with releases I would say the odds of this happening are low
> and is easily fixed by just changing a.
Ville's solution does fix my problem, but it creates another: if you have a, b, c in the same folder and you change one of them, a, b, c will have their checksums changed. I don't think the odds of this happening are low.
Just changing another file which didn't need to be changed just to keep Tapestry happy, I'm sorry, I think it's quite bad.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [5.4] Problems with the asset checksums and relative paths based
on them
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 12 Sep 2013 09:43:40 -0300, Barry Books <tr...@gmail.com> wrote:
> If you have file a b and c. The page includes a which then includes b
> and c but in your case with a's checksum.
In my case, Tapestry can't know that file a included b and c, because a,
which is JavaScript, dynamically included them in the page. It just knows
b and c were requested with wrong checksums.
> If Tapestry just returned b and c with
> a's checksum everything would work fine. The only problem would be if you
> change b or c without changing a. I agree this could be a problem but if
> you are using a library with releases I would say the odds of this
> happening are low and is easily fixed by just changing a.
Ville's solution does fix my problem, but it creates another: if you have
a, b, c in the same folder and you change one of them, a, b, c will have
their checksums changed. I don't think the odds of this happening are low.
Just changing another file which didn't need to be changed just to keep
Tapestry happy, I'm sorry, I think it's quite bad.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
VS: [5.4] Problems with the asset checksums and relative paths based on them
Posted by Ville Virtanen <vi...@orientimport.fi>.
The checsums are there for a reason, and I think this is the correct
approach.
The only thing missing in my opinion is to be able to declare that I want
the checksum for all assets inside directory x to be calculated from all the
assets in that directory. This way the checksum would be the same for all
the assets in the dir and change if any of the assets change, which would
lead to correct functionality in this WYMeditor example (the relative paths
would work then). Easy to upgrade too, drop in new version of WYMeditor and
Tap calculates new checksum for you and browsers react correctly. Don't
upgrade and let the browser caches work magic.
I think that would make sense for many third party integrations, and once
again, it would let Tap make a sensible default, but allow fallback if
needed. (And let the developer be king!
http://www.youtube.com/watch?v=8To-6VIJZRE :))
Ville
-----Alkuperäinen viesti-----
Lähettäjä: Barry Books [mailto:trsvax@gmail.com]
Lähetetty: 12. syyskuuta 2013 15:44
Vastaanottaja: Tapestry development
Aihe: Re: [5.4] Problems with the asset checksums and relative paths based
on them
If you have file a b and c. The page includes a which then includes b and c
but in your case with a's checksum. If Tapestry just returned b and c with
a's checksum everything would work fine. The only problem would be if you
change b or c without changing a. I agree this could be a problem but if you
are using a library with releases I would say the odds of this happening are
low and is easily fixed by just changing a.
In other words what's the benefit of the 404? The checksum is not meant to
be a security mechanism.
On Thu, Sep 12, 2013 at 6:54 AM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Wed, 11 Sep 2013 19:41:40 -0300, Barry Books <tr...@gmail.com> wrote:
>
> Perhaps a dumb question but why does the checksum need to match for
>> Tapestry to return the file? The only problem I can think of is if
>> the included file changes but the main file does not then the cached
>> file might be used.
>>
>
> What do you mean by included file and main file?
>
>
> I would think that's unlikely to happen
>>
>
> Actually, browsers not getting updated JS, CSS and image files after
> they were changed in the server is quite common without some mechanism
> like that. In T5.1 projects, many times I've had to ask the testers to
> clear their caches because they were testing the fix and the problem
> was still appearing because of the browser cache.
>
> I've actually fixed my problem by creating a request filter that
> checks for requests to files dynamically included by WYMeditor, find
> the original files in the classpath, generate a new Asset instance for
> them (which contains the right checksum) and redirects to it. Ugly,
> but fixes the problem. :)
>
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**------
> --- To unsubscribe, e-mail:
> dev-unsubscribe@tapestry.**apache.org<dev-unsubscribe@tapestry.apache.
> org> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [5.4] Problems with the asset checksums and relative paths based
on them
Posted by Howard Lewis Ship <hl...@gmail.com>.
What I was getting at was:
/assets/... -- normal assets, w/checksums
/assets.gz/... -- GZip compressed assets, w/ checksums
/xxx/... - redirects to /assets/... or /assets.gz/...
I'm trying to think of a short, reasonable name for "/xxx/".
Maybe we should give up, and have /a/ for the redirector, /ap/ for plain
assets, and /az/ for GZip assets? And maybe /m/ for AMD modules?
On Thu, Sep 12, 2013 at 12:25 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Thu, 12 Sep 2013 15:26:52 -0300, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
> No, I think redirect-to-correct-url is a good idea; I'm just not sure
>> what the URL will look like.
>>
>
> Like any one created from an Asset. If you are checking the file against a
> checksum, you know what the file is and where it is. So you can just use
> AssetSource to get an Asset instance pointing to it and its toClientURL()
> method provides you the URL to be redirected to. ;)
>
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apache.org<de...@tapestry.apache.org>
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: [5.4] Problems with the asset checksums and relative paths based
on them
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 12 Sep 2013 15:26:52 -0300, Howard Lewis Ship <hl...@gmail.com>
wrote:
> No, I think redirect-to-correct-url is a good idea; I'm just not sure
> what the URL will look like.
Like any one created from an Asset. If you are checking the file against a
checksum, you know what the file is and where it is. So you can just use
AssetSource to get an Asset instance pointing to it and its toClientURL()
method provides you the URL to be redirected to. ;)
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [5.4] Problems with the asset checksums and relative paths based
on them
Posted by Dimitris Zenios <di...@gmail.com>.
Any news on this?
On Fri, Sep 13, 2013 at 2:37 AM, Barry Books <tr...@gmail.com> wrote:
> if you have a url like a/123/b where 123 is the checksum of the parent file
> then do a 301 to /a/123_456/b where 456 is the checksum of b. If b changes
> then you can do another 301 to /a/123_789. If the parent file changes then
> it's a different 301.
>
>
> On Thu, Sep 12, 2013 at 1:26 PM, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
> > No, I think redirect-to-correct-url is a good idea; I'm just not sure
> what
> > the URL will look like.
> >
> > Ideally, we would rework /assets/modules/ to leverage this as well. May
> > improve page-to-page transitions if the user agent doesn't even have to
> > check to see if module resource has changed.
> >
> >
> > On Thu, Sep 12, 2013 at 11:13 AM, Thiago H de Paula Figueiredo <
> > thiagohp@gmail.com> wrote:
> >
> > > Ok, I agree with you with the 301 vs 302 issue. I just didn't
> understand
> > > whether you agree with the redirect-to-the-correct-URL-**instead-of-404
> > > suggestion. :)
> > >
> > >
> > > On Thu, 12 Sep 2013 14:49:01 -0300, Howard Lewis Ship <
> hlship@gmail.com>
> > > wrote:
> > >
> > > Not a 301 and here's why.
> > >>
> > >> The full URL, with checksum, represents an immutable resource.
> > >>
> > >> Changing the content of that resource is really replacing it with a
> new
> > >> immutable resource; that resource will have a different URL due to the
> > >> checksum.
> > >>
> > >> The redirecting-thing attempts to resolve the resource from partial
> > >> information: the path data. It redirects the current version of the
> > >> resource, and that's fine.
> > >>
> > >> However, I would not want it to be a permanent redirect, since that
> > might
> > >> prevent the same user agent from downloading a newer version of the
> > >> resource when that is available at a later date.
> > >>
> > >>
> > >>
> > >> On Thu, Sep 12, 2013 at 7:57 AM, Thiago H de Paula Figueiredo <
> > >> thiagohp@gmail.com> wrote:
> > >>
> > >> On Thu, 12 Sep 2013 09:43:40 -0300, Barry Books <tr...@gmail.com>
> > >>> wrote:
> > >>>
> > >>> In other words what's the benefit of the 404? The checksum is not
> > meant
> > >>>
> > >>>> to be a security mechanism.
> > >>>>
> > >>>>
> > >>> After fixing my problem here and reading your message, I wonder if
> > >>> Tapestry should redirect to the correct asset URL with a HTTP Error
> 301
> > >>> (Moved permanently) code.
> > >>>
> > >>>
> > >>> --
> > >>> Thiago H. de Paula Figueiredo
> > >>>
> > >>> ------------------------------****----------------------------**
> > >>> --**---------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apa**che.org<
> > http://apache.org>
> > >>> <dev-unsubscribe@**tapestry.apache.org<
> > dev-unsubscribe@tapestry.apache.org>
> > >>> >
> > >>>
> > >>>
> > >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> > > --
> > > Thiago H. de Paula Figueiredo
> > >
> > >
> ------------------------------**------------------------------**---------
> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apache.org<
> > dev-unsubscribe@tapestry.apache.org>
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > Howard M. Lewis Ship
> >
> > Creator of Apache Tapestry
> >
> > The source for Tapestry training, mentoring and support. Contact me to
> > learn how I can get you up and productive in Tapestry fast!
> >
> > (971) 678-5210
> > http://howardlewisship.com
> >
>
Re: [5.4] Problems with the asset checksums and relative paths based
on them
Posted by Barry Books <tr...@gmail.com>.
if you have a url like a/123/b where 123 is the checksum of the parent file
then do a 301 to /a/123_456/b where 456 is the checksum of b. If b changes
then you can do another 301 to /a/123_789. If the parent file changes then
it's a different 301.
On Thu, Sep 12, 2013 at 1:26 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> No, I think redirect-to-correct-url is a good idea; I'm just not sure what
> the URL will look like.
>
> Ideally, we would rework /assets/modules/ to leverage this as well. May
> improve page-to-page transitions if the user agent doesn't even have to
> check to see if module resource has changed.
>
>
> On Thu, Sep 12, 2013 at 11:13 AM, Thiago H de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
> > Ok, I agree with you with the 301 vs 302 issue. I just didn't understand
> > whether you agree with the redirect-to-the-correct-URL-**instead-of-404
> > suggestion. :)
> >
> >
> > On Thu, 12 Sep 2013 14:49:01 -0300, Howard Lewis Ship <hl...@gmail.com>
> > wrote:
> >
> > Not a 301 and here's why.
> >>
> >> The full URL, with checksum, represents an immutable resource.
> >>
> >> Changing the content of that resource is really replacing it with a new
> >> immutable resource; that resource will have a different URL due to the
> >> checksum.
> >>
> >> The redirecting-thing attempts to resolve the resource from partial
> >> information: the path data. It redirects the current version of the
> >> resource, and that's fine.
> >>
> >> However, I would not want it to be a permanent redirect, since that
> might
> >> prevent the same user agent from downloading a newer version of the
> >> resource when that is available at a later date.
> >>
> >>
> >>
> >> On Thu, Sep 12, 2013 at 7:57 AM, Thiago H de Paula Figueiredo <
> >> thiagohp@gmail.com> wrote:
> >>
> >> On Thu, 12 Sep 2013 09:43:40 -0300, Barry Books <tr...@gmail.com>
> >>> wrote:
> >>>
> >>> In other words what's the benefit of the 404? The checksum is not
> meant
> >>>
> >>>> to be a security mechanism.
> >>>>
> >>>>
> >>> After fixing my problem here and reading your message, I wonder if
> >>> Tapestry should redirect to the correct asset URL with a HTTP Error 301
> >>> (Moved permanently) code.
> >>>
> >>>
> >>> --
> >>> Thiago H. de Paula Figueiredo
> >>>
> >>> ------------------------------****----------------------------**
> >>> --**---------
> >>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apa**che.org<
> http://apache.org>
> >>> <dev-unsubscribe@**tapestry.apache.org<
> dev-unsubscribe@tapestry.apache.org>
> >>> >
> >>>
> >>>
> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>>
> >>>
> >>>
> >>
> >>
> >
> > --
> > Thiago H. de Paula Figueiredo
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apache.org<
> dev-unsubscribe@tapestry.apache.org>
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
Re: [5.4] Problems with the asset checksums and relative paths based
on them
Posted by Howard Lewis Ship <hl...@gmail.com>.
No, I think redirect-to-correct-url is a good idea; I'm just not sure what
the URL will look like.
Ideally, we would rework /assets/modules/ to leverage this as well. May
improve page-to-page transitions if the user agent doesn't even have to
check to see if module resource has changed.
On Thu, Sep 12, 2013 at 11:13 AM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Ok, I agree with you with the 301 vs 302 issue. I just didn't understand
> whether you agree with the redirect-to-the-correct-URL-**instead-of-404
> suggestion. :)
>
>
> On Thu, 12 Sep 2013 14:49:01 -0300, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
> Not a 301 and here's why.
>>
>> The full URL, with checksum, represents an immutable resource.
>>
>> Changing the content of that resource is really replacing it with a new
>> immutable resource; that resource will have a different URL due to the
>> checksum.
>>
>> The redirecting-thing attempts to resolve the resource from partial
>> information: the path data. It redirects the current version of the
>> resource, and that's fine.
>>
>> However, I would not want it to be a permanent redirect, since that might
>> prevent the same user agent from downloading a newer version of the
>> resource when that is available at a later date.
>>
>>
>>
>> On Thu, Sep 12, 2013 at 7:57 AM, Thiago H de Paula Figueiredo <
>> thiagohp@gmail.com> wrote:
>>
>> On Thu, 12 Sep 2013 09:43:40 -0300, Barry Books <tr...@gmail.com>
>>> wrote:
>>>
>>> In other words what's the benefit of the 404? The checksum is not meant
>>>
>>>> to be a security mechanism.
>>>>
>>>>
>>> After fixing my problem here and reading your message, I wonder if
>>> Tapestry should redirect to the correct asset URL with a HTTP Error 301
>>> (Moved permanently) code.
>>>
>>>
>>> --
>>> Thiago H. de Paula Figueiredo
>>>
>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apa**che.org<http://apache.org>
>>> <de...@tapestry.apache.org>
>>> >
>>>
>>>
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>>
>>
>>
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apache.org<de...@tapestry.apache.org>
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: VS: [5.4] Problems with the asset checksums and relative paths
based on them
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 12 Sep 2013 15:48:03 -0300, Ville Virtanen
<vi...@orientimport.fi> wrote:
> Won't this lead browser's cache to be never used? 302 instructs browser
> that this is a temporary redirect and should be re-checked on next
> access?
The browser cache won't be used for the request for the wrong URL, but it
will for the redirected one. Not a perfect solution, but probably the best
one we can use. Anyway, this behavior would only be triggered for corner
cases like the WYMeditor loading stuff by itself one.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
VS: [5.4] Problems with the asset checksums and relative paths based on them
Posted by Ville Virtanen <vi...@orientimport.fi>.
Won't this lead browser's cache to be never used? 302 instructs browser that this is a temporary redirect and should be re-checked on next access?
Ville
-----Alkuperäinen viesti-----
Lähettäjä: Thiago H de Paula Figueiredo [mailto:thiagohp@gmail.com]
Lähetetty: 12. syyskuuta 2013 21:13
Vastaanottaja: Tapestry development
Aihe: Re: [5.4] Problems with the asset checksums and relative paths based on them
Ok, I agree with you with the 301 vs 302 issue. I just didn't understand whether you agree with the redirect-to-the-correct-URL-instead-of-404
suggestion. :)
On Thu, 12 Sep 2013 14:49:01 -0300, Howard Lewis Ship <hl...@gmail.com>
wrote:
> Not a 301 and here's why.
>
> The full URL, with checksum, represents an immutable resource.
>
> Changing the content of that resource is really replacing it with a
> new immutable resource; that resource will have a different URL due to
> the checksum.
>
> The redirecting-thing attempts to resolve the resource from partial
> information: the path data. It redirects the current version of the
> resource, and that's fine.
>
> However, I would not want it to be a permanent redirect, since that
> might prevent the same user agent from downloading a newer version of
> the resource when that is available at a later date.
>
>
>
> On Thu, Sep 12, 2013 at 7:57 AM, Thiago H de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
>> On Thu, 12 Sep 2013 09:43:40 -0300, Barry Books <tr...@gmail.com>
>> wrote:
>>
>> In other words what's the benefit of the 404? The checksum is not
>> meant
>>> to be a security mechanism.
>>>
>>
>> After fixing my problem here and reading your message, I wonder if
>> Tapestry should redirect to the correct asset URL with a HTTP Error
>> 301 (Moved permanently) code.
>>
>>
>> --
>> Thiago H. de Paula Figueiredo
>>
>> ------------------------------**------------------------------**-----
>> ----
>> To unsubscribe, e-mail:
>> dev-unsubscribe@tapestry.**apache.org<dev-unsubscribe@tapestry.apache
>> .org>
>>
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [5.4] Problems with the asset checksums and relative paths based
on them
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
Ok, I agree with you with the 301 vs 302 issue. I just didn't understand
whether you agree with the redirect-to-the-correct-URL-instead-of-404
suggestion. :)
On Thu, 12 Sep 2013 14:49:01 -0300, Howard Lewis Ship <hl...@gmail.com>
wrote:
> Not a 301 and here's why.
>
> The full URL, with checksum, represents an immutable resource.
>
> Changing the content of that resource is really replacing it with a new
> immutable resource; that resource will have a different URL due to the
> checksum.
>
> The redirecting-thing attempts to resolve the resource from partial
> information: the path data. It redirects the current version of the
> resource, and that's fine.
>
> However, I would not want it to be a permanent redirect, since that might
> prevent the same user agent from downloading a newer version of the
> resource when that is available at a later date.
>
>
>
> On Thu, Sep 12, 2013 at 7:57 AM, Thiago H de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
>> On Thu, 12 Sep 2013 09:43:40 -0300, Barry Books <tr...@gmail.com>
>> wrote:
>>
>> In other words what's the benefit of the 404? The checksum is not meant
>>> to be a security mechanism.
>>>
>>
>> After fixing my problem here and reading your message, I wonder if
>> Tapestry should redirect to the correct asset URL with a HTTP Error 301
>> (Moved permanently) code.
>>
>>
>> --
>> Thiago H. de Paula Figueiredo
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail:
>> dev-unsubscribe@tapestry.**apache.org<de...@tapestry.apache.org>
>>
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [5.4] Problems with the asset checksums and relative paths based
on them
Posted by Howard Lewis Ship <hl...@gmail.com>.
Not a 301 and here's why.
The full URL, with checksum, represents an immutable resource.
Changing the content of that resource is really replacing it with a new
immutable resource; that resource will have a different URL due to the
checksum.
The redirecting-thing attempts to resolve the resource from partial
information: the path data. It redirects the current version of the
resource, and that's fine.
However, I would not want it to be a permanent redirect, since that might
prevent the same user agent from downloading a newer version of the
resource when that is available at a later date.
On Thu, Sep 12, 2013 at 7:57 AM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Thu, 12 Sep 2013 09:43:40 -0300, Barry Books <tr...@gmail.com> wrote:
>
> In other words what's the benefit of the 404? The checksum is not meant
>> to be a security mechanism.
>>
>
> After fixing my problem here and reading your message, I wonder if
> Tapestry should redirect to the correct asset URL with a HTTP Error 301
> (Moved permanently) code.
>
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apache.org<de...@tapestry.apache.org>
>
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: [5.4] Problems with the asset checksums and relative paths based
on them
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 12 Sep 2013 09:43:40 -0300, Barry Books <tr...@gmail.com> wrote:
> In other words what's the benefit of the 404? The checksum is not meant
> to be a security mechanism.
After fixing my problem here and reading your message, I wonder if
Tapestry should redirect to the correct asset URL with a HTTP Error 301
(Moved permanently) code.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [5.4] Problems with the asset checksums and relative paths based
on them
Posted by Barry Books <tr...@gmail.com>.
If you have file a b and c. The page includes a which then includes b and c
but in your case with a's checksum. If Tapestry just returned b and c with
a's checksum everything would work fine. The only problem would be if you
change b or c without changing a. I agree this could be a problem but if
you are using a library with releases I would say the odds of this
happening are low and is easily fixed by just changing a.
In other words what's the benefit of the 404? The checksum is not meant to
be a security mechanism.
On Thu, Sep 12, 2013 at 6:54 AM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Wed, 11 Sep 2013 19:41:40 -0300, Barry Books <tr...@gmail.com> wrote:
>
> Perhaps a dumb question but why does the checksum need to match for
>> Tapestry to return the file? The only problem I can think of is if the
>> included file changes but the main file does not then the cached file
>> might be used.
>>
>
> What do you mean by included file and main file?
>
>
> I would think that's unlikely to happen
>>
>
> Actually, browsers not getting updated JS, CSS and image files after they
> were changed in the server is quite common without some mechanism like
> that. In T5.1 projects, many times I've had to ask the testers to clear
> their caches because they were testing the fix and the problem was still
> appearing because of the browser cache.
>
> I've actually fixed my problem by creating a request filter that checks
> for requests to files dynamically included by WYMeditor, find the original
> files in the classpath, generate a new Asset instance for them (which
> contains the right checksum) and redirects to it. Ugly, but fixes the
> problem. :)
>
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apache.org<de...@tapestry.apache.org>
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: [5.4] Problems with the asset checksums and relative paths based
on them
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Wed, 11 Sep 2013 19:41:40 -0300, Barry Books <tr...@gmail.com> wrote:
> Perhaps a dumb question but why does the checksum need to match for
> Tapestry to return the file? The only problem I can think of is if the
> included file changes but the main file does not then the cached file
> might be used.
What do you mean by included file and main file?
> I would think that's unlikely to happen
Actually, browsers not getting updated JS, CSS and image files after they
were changed in the server is quite common without some mechanism like
that. In T5.1 projects, many times I've had to ask the testers to clear
their caches because they were testing the fix and the problem was still
appearing because of the browser cache.
I've actually fixed my problem by creating a request filter that checks
for requests to files dynamically included by WYMeditor, find the original
files in the classpath, generate a new Asset instance for them (which
contains the right checksum) and redirects to it. Ugly, but fixes the
problem. :)
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [5.4] Problems with the asset checksums and relative paths based
on them
Posted by Barry Books <tr...@gmail.com>.
Perhaps a dumb question but why does the checksum need to match for
Tapestry to return the file? The only problem I can think of is if the
included file changes but the main file does not then the cached file might
be used. I would think that's unlikely to happen and could easily be solved
by just changing the main file. The current problem is difficult to solve.
On Wed, Sep 11, 2013 at 9:16 AM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Tue, 10 Sep 2013 22:25:18 -0300, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
> This is a tricky one to handle.
>>
>
> Yep. I still couldn't find a good, simple solution yet. The whole
> classpath asset support code is built on the top of the checksums.
>
>
> It feels like we need yet another Asset URL path that works more like
>> modules: no checksum in the URL and no far-future expires header, but
>> maybe e-tags support.
>>
>
> What about something like a "simpleclasspath" binding that does everything
> the normal classpath one does but without the checksum?
>
>
> Alternately, using the WYMeditor configuration, we could follow up on the
>> idea I had on the user mailing list: an alternate asset URL that sends a
>> proper redirect to the real asset. So /X/meta/wymeditor/foo.css would be
>> redirected to /assets.gz/meta/wymeditor/**abc123/foo.css.
>>
>
> That's a good idea, but it wouldn't solve the problem I'm having now.
>
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apache.org<de...@tapestry.apache.org>
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: [5.4] Problems with the asset checksums and relative paths based
on them
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 10 Sep 2013 22:25:18 -0300, Howard Lewis Ship <hl...@gmail.com>
wrote:
> This is a tricky one to handle.
Yep. I still couldn't find a good, simple solution yet. The whole
classpath asset support code is built on the top of the checksums.
> It feels like we need yet another Asset URL path that works more like
> modules: no checksum in the URL and no far-future expires header, but
> maybe e-tags support.
What about something like a "simpleclasspath" binding that does everything
the normal classpath one does but without the checksum?
> Alternately, using the WYMeditor configuration, we could follow up on the
> idea I had on the user mailing list: an alternate asset URL that sends a
> proper redirect to the real asset. So /X/meta/wymeditor/foo.css would be
> redirected to /assets.gz/meta/wymeditor/abc123/foo.css.
That's a good idea, but it wouldn't solve the problem I'm having now.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org