On Wed, Jan 18, 2012 at 12:39:27AM +0100, Lubos Kosco wrote: > Well > I agree with all your points, but you forgot about one small thing - > this is not ideally implemented world - and there is a client, too
Yepp. > Afaik Firefox had the cache problem back when we started hitting the > problem(I think it was upgrade from 0.8 to 0.9) and IE has it for ages. > Even if headers properly indicate the change, the cache will be used and > not refreshed for css and js files (there are even some hardcodes like > e.g. a week until the cache check is forced, etc.) . I'm not convinced. IMHO at least modern browsers follow specifications, but they may interpret things differently (optimized), if the server does not clearly tell them the facts/its intention. If nothing special happens, I'll try to do some checks/research on this at this weekend ... > I know that is a dirty hack ... but IT WORKS for MOST of people. And this is exactly what brought us the "You need the MS IE to properly see this page" and still strikes Mozilla/Opera/etc users, just because "designers" thought, it is a good thing to ignore standards and just code it in a way, that it works for "most" people ... So yes, some concession wrt. to non-essential stuff like making the UI look a little bit better are ok, but somewhere a line needs to be drawn. Fakeing static content to look like dynamic content is simply wrong ... (a police officer jokes jumps right into my mind: it looks like ..., it smells like ..., it tastes like ... - ooops :)) > And browsers DO cache it even with parameters, just test it, you'll see. Yes, I'll test. If it is the case, a filter should be implemented, which adds appropriote headers to make sure, that the client understands, what the server wants. > I know you mean it to be properly done - and I DO LIKE that approach. > Things should be proper, if everybody plays well. Does everybody play well? > > There is one more point of view - it has to work out of box (tm) and for > 99% of target audience. Hmmm, 99% is a high goal for more or less sophisticated UIs/browsers. So one should invest more time in investigating the root cause instead of simply targeting the symptoms. Also I think, the target audience are not business people, so assuming they are somehow disabled when using its preferred tools might mislead as well. > How does one achieve that? > Definitely not by forcing someone to change, but to change yourself. To > bend the spoon, you have to bend yourself ... even if it means not to > play 100% by rules, but still in certain boundaries ;) Somehow: bending a little bit is ok, but taking its brain completely offline and becoming a robot leads to undesirable development (former GDR citizen know what I mean ;-)). > hmm? Yes. Cheers, jel. > On 18.1.2012 0:13, Jens Elkner wrote: > >On Tue, Jan 17, 2012 at 04:25:16PM +0100, Lubos Kosco wrote: > >>I have a stopper > >> > >>Jens changed the way how we include stylesheets > >> > >>http://src.opensolaris.org/source/diff/opengrok/trunk/web/httpheader.jspf?r2=%2Fopengrok%2Ftrunk%2Fweb%2Fhttpheader.jspf%401186%3Aa7c1c479ae41&r1=%2Fopengrok%2Ftrunk%2Fweb%2Fhttpheader.jspf%401174%3A09f0768a7ec1 > >> > >>- Jens that was there for a reason - if the stylesheet just says > >Yes, I changed it for reason as well: to allow propper caching. IMHO it > >is just plain wrong, to make static content appear "dynamic" and thus > >uncachable just because a strange setup (proxy in front) or server does > >the wrong thing. > > > >>style.css without version, browser will not replace its copy upon > >>opengrok update and has stale cache ! > >Well, not sure what tomcat does, but since glassfish is using a lot of > >tomcat stuff, I think the behavior is not different: They send Etags and > >Last-Modified-Dates. The browser asks the server to send the file, if it > >has been modified since the last modified date the browser knows about > >or the Etag changed. Both is the case, when the file has been changed > >(or one needs to put a lot of work into the app, to fake it to appear as > >it was sent last time). E.g: > > > >REQUEST: > >-------- > >Host src.iws.cs.ovgu.de > >User-Agent Mozilla/5.0 (X11; SunOS i86pc; rv:7.0.1) Gecko/20100101 > >Firefox/7.0.1 > >Accept text/css,*/*;q=0.1 > >Accept-Language de-DE,de;q=1.0,en-US,en;q=0.8,de-DE;q=0.5,de;q=0.3 > >Accept-Encoding gzip, deflate > >Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7 > >Connection keep-alive > >Referer http://src.iws.cs.ovgu.de/source/xref/opengrok/ > >Cookie OpenGrokProject=opengrok; OpenGrokSorting=relevancy > >If-Modified-Since Fri, 20 May 2011 19:30:26 GMT > >If-None-Match W/"13344-1305919826000" > >Cache-Control max-age=0 > > > >RESPONSE: > >--------- > >X-Powered-By Servlet/3.0 JSP/2.2 (GlassFish Server Open Source > >Edition 3.1 Java/Sun Microsystems Inc./1.6) > >Server GlassFish Server Open Source Edition 3.1 > >Etag W/"13344-1305919826000" > >Date Tue, 17 Jan 2012 22:51:51 GMT > > > >CACHE: > >------ > >Last Modified Tue Jan 17 2012 23:51:51 GMT+0100 (CET) > >Last Fetched Tue Jan 17 2012 23:51:51 GMT+0100 (CET) > >Expires Sat Feb 11 2012 04:59:59 GMT+0100 (CET) > >Data Size 13344 > >Fetch Count 66 > >Device disk > > > >So IMHO it seems to be a proxy misconfiguration or one should configure > >the server to provide Etags. > > > >>so above changeset should be checked for regressions and at least style > >>sheet versioning using ?xxx has to come back ! > >IMHO not. > > > >Regards, > >jel. > > > >>On 17.1.2012 16:16, Knut Anders Hatlen wrote: > >>>Vladimir Kotal<vladimir.ko...@oracle.com> writes: > >>> > >>>>On 01/16/12 16:18, Knut Anders Hatlen wrote: > >>>>>Trond Norbye<trond.nor...@gmail.com> writes: > >>>>> > >>>>>>Or is anyone working on fixing this? > >>>>>I guess the lack of response answers this question... > >>>>> > >>>>>As to the question about reverting the changes, does anyone know what > >>>>>would be the minimum to back out in order to get the old behaviour > >>>>>back? > >>>>>The UI changes came in as part of a pretty big refactoring patch, IIRC, > >>>>>and probably many of the changes that have gone in later depend on the > >>>>>refactoring, so reverting the UI stuff isn't necessarily easier than > >>>>>fixing it. > >>>>> > >>>>Only couple of minor changes are necessary to fix the UI. I am going > >>>>to fix the '..' link. > >>>I've changed the style sheets so that the browser's default fonts are > >>>used, which seems to fix the issue with too big fonts. (Not sure it > >>>fixed the related issue with too small fonts mentioned in the bug > >>>report. Vlad, you might want to double-check that.) > >>> > >>>That leaves only two issues to be fixed on bug #19105, I think: > >>> > >>>1) Missing white lines between code lines (perhaps not a stopper?) > >>> > >>>2) Garbled headers in Internet Explorer > >>> > >>_______________________________________________ > >>opengrok-discuss mailing list > >>opengrok-discuss@opensolaris.org > >>http://mail.opensolaris.org/mailman/listinfo/opengrok-discuss > > _______________________________________________ > opengrok-discuss mailing list > opengrok-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/opengrok-discuss -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768 _______________________________________________ opengrok-discuss mailing list opengrok-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opengrok-discuss
