P.S. Observing ApplicationWillDispatchRequestNotification, in all the cases
(i.e., with relative "../fonts...", with absolute "/dms/css..." and even with
"http://localhost:56005/dms/css
<http://localhost:56005/dms/css/font-awesome>...") I am always getting the same
URIs in the requests, they always look like this:
WILLDISPATCH <er.extensions.appserver.ERXRequest
(<er.extensions.appserver.ERXRequest httpVersion=HTTP/1.1
headers={accept=[*/*], accept-encoding=[gzip, deflate],
accept-language=[en-gb], connection=[keep-alive],
cookie=[routeid_sberdat=.sberdat_56005], host=[localhost:56005],
referer=[http://localhost:56005/cgi-bin/WebObjects/CEBOIS.woa/wo/9MQqLwIwOvKbx5fanbf3w0/5.0.0.9.1.1.1.0.1.1.1],
user-agent=[Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6)
AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.2 Safari/605.1.15]}
content-length=0 cookies=null userInfo={} storePageInBacktrackCache=true >)
method=GET uri=/dms/css/font-awesome/fonts/fontawesome-webfont.svg?v=4.6.3
defaultFormValueEncoding=UTF-8 formValueEncodingDetectionEnabled=NO
formValueEncoding=UTF-8 formValues={v = ("4.6.3"); } >
Weird. What might be the culprit? Hardly the referer; it would not make sense,
and besides, to make sure, I have tried request.setHeader('','referer') in the
ApplicationWillDispatchRequestNotification handler, which did not help either.
I must admit I can't see even what to try now :-O
Thanks,
OC
> On 10 Jan 2020, at 2:29 PM, ocs@ocs <o...@ocs.cz> wrote:
>
> Chuck,
>
> thanks!
>
>> On 10 Jan 2020, at 7:23 AM, Chuck Hill <hill.ch...@gmail.com
>> <mailto:hill.ch...@gmail.com>> wrote:
>> I am pretty sure it is the relative URLs in font-awesome.min.css. They get
>> evaluated as relative to the URL of your page not the URL of that CSS.
>
> That idea occurred to me too, but I think in that case it would not work
> (would not render the characters properly), for the fonts would not be loaded
> at all from such bogus URLs, would they?
>
> Anyway I have tried to change the URLs in the CSS file to absolute ones like
> this:
>
> ===
> @font-face {
> font-family: 'FontAwesome';
> src: url('/dms/css/font-awesome/fonts/fontawesome-webfont.eot?v=4.6.3');
> src:
> url('/dms/css/font-awesome/fonts/fontawesome-webfont.eot?#iefix&v=4.6.3')
> format('embedded-opentype'),
> url('/dms/css/font-awesome/fonts/fontawesome-webfont.woff2?v=4.6.3')
> format('woff2'),
> url('/dms/css/font-awesome/fonts/fontawesome-webfont.woff?v=4.6.3')
> format('woff'),
> url('/dms/css/font-awesome/fonts/fontawesome-webfont.ttf?v=4.6.3')
> format('truetype'),
> url('/dms/css/font-awesome/fonts/fontawesome-webfont.svg?v=4.6.3#fontawesomeregular')
> format('svg');
> font-weight: normal;
> font-style:normal
> }
> ===
>
> and the problem persists. It persists even if I use complete URLs incl. the
> server, like “http://localhost:56005/dms/css/font-awesome
> <http://localhost:56005/dms/css/font-awesome>...”, which I tried too.
>
> So, triple alas, that would not be the culprit, I fear.
>
> Thanks and all the best,
> OC
>
>>> On Jan 9, 2020, at 5:48 PM, OCsite via Webobjects-dev
>>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>>
>>> wrote:
>>>
>>> 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
>>> <http://fontawesome.io/> - @fontawesome
>>> * License - http://fontawesome.io/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 (Webobjects-dev@lists.apple.com
>>> <mailto:Webobjects-dev@lists.apple.com>)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/hill.chuck%40gmail.com
>>>
>>> <https://lists.apple.com/mailman/options/webobjects-dev/hill.chuck%40gmail.com>
>>>
>>> This email sent to hill.ch...@gmail.com
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
