suspicious sessions and R/R loops created for a CSS font
suspicious sessions and R/R loops created for a CSS font
- Subject: suspicious sessions and R/R loops created for a CSS font
- From: OCsite via Webobjects-dev <email@hidden>
- Date: Fri, 10 Jan 2020 02:48:13 +0100
Gentlemen,
my application does some R/R loops and creates some sessions/main components
which I believe it should not.
Lately, from a webdesigner, I have got some improvements of the look of my
application, which essentially looks like
<link rel="stylesheet" type="text/css"
href="/dms/css/font-awesome/css/font-awesome.min.css"/>
in the html header. The CSS starts with
===
/*!
* Font Awesome 4.6.3 by @davegandy - http://fontawesome.io - @fontawesome
* License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT
License)
*/@font-face {
font-family: 'FontAwesome';
src: url('../fonts/fontawesome-webfont.eot?v=4.6.3');
src: url('../fonts/fontawesome-webfont.eot?#iefix&v=4.6.3')
format('embedded-opentype'), url('../fonts/fontawesome-webfont.woff2?v=4.6.3')
format('woff2'), url('../fonts/fontawesome-webfont.woff?v=4.6.3')
format('woff'), url('../fonts/fontawesome-webfont.ttf?v=4.6.3')
format('truetype'),
url('../fonts/fontawesome-webfont.svg?v=4.6.3#fontawesomeregular')
format('svg');
font-weight: normal;
font-style:normal
}
===
Then, things like
<i class="fa fa-plus" aria-hidden="true"></i>
are used throughout the component templates, with the appropriate classes
looking like
===
.fa {
display: inline-block;
font: normal normal normal 14px/1 FontAwesome;
font-size: inherit;
text-rendering: auto;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing:grayscale
}
.fa-plus:before {
content: "\f067"
}
===
It seems to render the characters all right, but the reason why I am writing is
that as soon as the <i class...> thing is used in the page, I am getting VERY
suspicious R/R loops and extra sessions. Namely, what I see is that
1. normal R/R loop for the standard URI "...myapp/wo/SID/COMPONENT" happens,
uses the long-ago-created session for SID as it should, ends by
application.sleep(). Precisely same as if there's no <i class...>, so far so
good.
But, if there _is_ an <i class...> thing in the page, I immediately and
automatically (without doing anything in the browser) get another four R/R
loops (far as I can say, served by the same thread as the first normal one);
each of them creates a new session and a Main page (which is never shown
anywhere), and if I log out its context().request() in the newly created
session's awake(), it seems self-evident these R/R loops are created for the
URIs from the CSS header, namely
2. ../fonts/fontawesome-webfont.woff2?v=4.6.3
3. ../fonts/fontawesome-webfont.woff?v=4.6.3
4. ../fonts/fontawesome-webfont.ttf?v=4.6.3
5. ../fonts/fontawesome-webfont.svg?v=4.6.3
(For some reason, for those .eot URIs this does not happen.)
Now, I understand that the fonts need to be loaded; nevertheless, it does not
feel right that a full-fledged R/R loop, which creates a session and a Main
page, is created and run for this.
Is that right? As always, I might be overlooking something of importance, but
to me this feels wrong; there should be no need to create a full-fledged R/R
for this, far as I understand. There are many other resources/CSSs/javascripts
the application uses (incl. the very "font-awesome.min.css"), and none of them
causes this; they all are loaded without R/R loops, without sessions, etc.
The designer knows sweet zilch of WebObjects and says if there's a problem at
all, it's caused by my application around his perfect and flawless CSS. Well
perhaps it is indeed; but I can't see the culprit.
Does anybody here understand the problem and can say how to fix it (or, at
worst, that it is unfixable in principle and I have to bear with it)?
Thanks a lot,
OC
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden