RE: Prebuilt binary Apache 2.4 Adaptor

[GILQUIN Pierre via Webobjects-dev]

Hi Gino,

I was abled to compile a 2.4 module in centos 7.following instructions here:
https://wiki.wocommunity.org/display/documentation/Installing+a+deployment+environment+on+RedHat%2C+CentOS+or+Amazon+Linux

$ git clone https://github.com/wocommunity/wonder.git
$ cd wonder/Utilities/Adaptors
$ sed -ri 's/ADAPTOR_OS = MACOS/ADAPTOR_OS = LINUX/g' make.config
$ sed -ri 's/ADAPTORS = CGI Apache2.2/ADAPTORS = Apache2.4/g' make.config
$ make

Et voilà 
Pierre


-Message d'origine-
De : Webobjects-dev 
[mailto:webobjects-dev-bounces+pierre.gilquin=hcuge...@lists.apple.com] De la 
part de Gino Pacitti via Webobjects-dev
Envoyé : vendredi 10 janvier 2020 22:17
À : WebObjects-Dev Mailing List List
Objet : Prebuilt binary Apache 2.4 Adaptor

Hi there..
Is there a link out there anywhere for the Apache.conf file and the 
mod_Webobjects.so apache module?

I did an update to a local machine to 2.14.* Apache and now apps are reported 
as not being found on the server.

Any help appreciated

Gino 
 ___
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/pierre.gilquin%40hcuge.ch

This email sent to pierre.gilq...@hcuge.ch
 ___
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

More SharedEC woes: relationships into SEC not saved?!?

[OCsite via Webobjects-dev]

Hi there,

this is weird. My EOs have some relationships into the SharedEC — of course, 
one-way without an inverse; I understand that relationships to SEC are all 
right, only those from it outside are forbidden. (Am I wrong perhaps? If those 
relationships were set up in the database without SEC, it works perfectly.)

Nevertheless, when I run with SEC, whatever I try, it seems these relationships 
are — silently and without reporting any problem — not saved.

Say, I have an EO foo of entity Foo with two simple :1 relationships: a (based 
on FK a_id) into a normal-EC entity, and b (based on FK b_id) into a shared-EC 
entity. Both are modelled the same way (simple join from the FK in the source 
entity to the PK of the target entity). I set both of them, like this:

===
ERXEC ec=
Foo foo=new Foo()
ec.insertObject(foo)
assert ec==someObject.editingContext()
foo.a=someObject
assert ec.sharedEditingContext()==someSharedObject.editingContext()
foo.b=someSharedObject
assert foo.b==someSharedObject
ec.saveChanges()
===

Now, changes are saved, no error is reported, new object is properly inserted 
into the database
- its a_id is filled by someObject's PK
- whilst its b_id is filled by NSKeyValueCoding$Null!

Same happens when editing: the relationships to SEC when changed never seem to 
save the appropriate FK value. It seems completely ignored by the saving 
process:

===
assert 
foo.editingContext().sharedEditingContext()==anotherSharedObject.editingContext()
foo.b=anotherSharedObject
assert foo.b==anotherSharedObject
assert foo.committedSnapshotValueForKey('b')==NSKeyValueCoding$Null
assert foo.changesFromCommittedSnapshot==[b: anotherSharedObject]
foo.editingContext().saveChanges()
assert foo.b==null
===

other changes of foo (if any) are saved all right, but its b_id never changes. 
No error is reported.

Does this make any sense, is it perhaps an expected behaviour? As always, I 
might be overlooking something of importance, but this feels completely wrong 
to me. Could it be caused by some bug at my side? If so, any idea where and how 
to hunt for it?

Thanks a lot for any insight,
OC

 ___
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

Sorta solved: suspicious sessions and R/R loops created for a CSS font

[OCsite via Webobjects-dev]

Hugi,

thanks!

> On 10 Jan 2020, at 20:19, Hugi Thordarson  wrote:
> Well, WOStaticResourceRequestHandler doesn't really "create a 
> request/response loop". A request is is sent to the application, the 
> application will then look at the URL and determine from that what request 
> handler should handle the request. That handler then generates a response.

That's how I understand it. Furthermore, do please correct me if I am wrong, 
but I understand that the ComponentRequestHandler does that by running an R/R 
loop, whilst most other handlers do not.

> In this case WO has determined WOStaticResourceRequestHandler is your guy, 
> but I'm not sure why, because thi URL should really just throw an error 
> (which makes me think there's more going on here).

Here is begins to be interesting. Probably I do not understand the behaviour 
quite properly.

Far as I can say, all those request handlers are not documented anywhere (if 
there's a documentation for them, I'd be grateful for a link to it), but I have 
always thought that the WOStaticResourceRequestHandler is there just to handle 
fixed URIs like this one.

After all, my jQuery, referenced in the HTML header using



gets actually loaded — far as I can say —for a very similar URI  by this very 
handler, and it works all right, no extra R/R happens here:

===
WorkerThread6 WILLDISPATCH http://localhost:56005/cgi-bin/WebObjects/CEBOIS.woa/wo/9UuJz2GsVhmGAeV07uiU2g/2.0.0.9.1.1.1.0.3.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/js/jquery-3.1.0.min.js defaultFormValueEncoding=UTF-8 
formValueEncodingDetectionEnabled=NO formValueEncoding=UTF-8 formValues={} >
WorkerThread6 WILLGETHANDLER ''
WorkerThread6 DIDGETHANDLER ?NULL?
WorkerThread6 WILLGETHANDLER '_wr_'
WorkerThread6 DIDGETHANDLER '_wr_' -> class 
com.webobjects.appserver._private.WOStaticResourceRequestHandler
===

> Anyhow… Judging from your request logs, you're either running in direct 
> connect mode

Right, the logs came from my development machine which runs direct connect. I 
know it's a bit old-fashioned, but so far I did not bump into any problem which 
would cause me to switch (and I've checked the production server logs to make 
sure the bogus R/R's happen there just as well, i.e., they are not caused by 
direct connect, but by another quirk).

> ... So don't use absolute URLs like that.

So far, there was no problem with them for years and years, neither development 
nor deployment side. Perhaps we just got lucky so far.

> Chuck's initial comment was probably right on the money; the relative 
> references in your CSS-file weren't resolving correctly to a file. Start by 
> checking that. If you kept the directory structure provided by your designer 
> when copying in the CSS-files/template, it really should just work.

> Alternatively, you can change your CSS-files to reference full URLs (i.e. 
> including domain, or really; just the full resource URL you know works) when 
> referencing the resources in question.

Alas fear not, as I wrote

===
> On 10 Jan 2020, at 14:29, ocs@ocs  wrote:
> I have tried to change the URLs in the CSS file to absolute ones like this:
> ...
> src: url('/dms/css/font-awesome/fonts/fontawesome-webfont.eot?v=4.6.3');
> ...
> and the problem persists. It persists even if I use complete URLs incl. the 
> server, like “http://localhost:56005/dms/css/font-awesome 
> ...”, which I tried too.

===

> ... As always, It's kind of difficult to assist without knowing or seeing the 
> project or setup, but hopefully the suggestions help :).

Regardless above, strangely, they did: they led me to think about those URLs 
and, well, although I have abso-bloomin-lootely no idea of how the @font-face 
thing should work, those form elements and even one fragment looked darn 
suspicious. The refs are just to load the font file contents from the given 
URL, aren't they? In which case form does not make any sense far as I can say.

Anyway, removing them did help — the bogus R/Rs immediately disappeared!

But for one, the “fontawesome-webfont.woff2” for some godforsaken reason did 
generate still one — now just one instead of original 4 — bogus R/Rs. Here 
though I found I can remove the thing altogether and it still works (presumably 
all the comma-separated URIs in there just offer alternatives for different 
font formats not/supported by the browser).

So, it seems that the WOStaticResourceRequestHandler would create a bogus R/R 
loop if there is a form at the end of the URL; removing the form removes the 
R/R loop too.

That's not the whole story — there would be other conditions which cause the 
R/R loop to be run, which did 

Prebuilt binary Apache 2.4 Adaptor

[Gino Pacitti via Webobjects-dev]

Hi there..
Is there a link out there anywhere for the Apache.conf file and the 
mod_Webobjects.so apache module?

I did an update to a local machine to 2.14.* Apache and now apps are reported 
as not being found on the server.

Any help appreciated

Gino 
 ___
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

Re: suspicious sessions and R/R loops created for a CSS font

[Hugi Thordarson via Webobjects-dev]

Well, WOStaticResourceRequestHandler doesn't really "create a request/response 
loop". A request is is sent to the application, the application will then look 
at the URL and determine from that what request handler should handle the 
request. That handler then generates a response. In this case WO has determined 
WOStaticResourceRequestHandler is your guy, but I'm not sure why, because thi 
URL should really just throw an error (which makes me think there's more going 
on here).

Anyhow… Judging from your request logs, you're either running in direct connect 
mode or redirecting requests for the web server root ("/") directly to your 
application, which obviously has no idea how to handle URLs that look like 
this. So don't use absolute URLs like that.

Chuck's initial comment was probably right on the money; the relative 
references in your CSS-file weren't resolving correctly to a file. Start by 
checking that. If you kept the directory structure provided by your designer 
when copying in the CSS-files/template, it really should just work.

Alternatively, you can change your CSS-files to reference full URLs (i.e. 
including domain, or really; just the full resource URL you know works) when 
referencing the resources in question. It could at least help until you figure 
out what's going on with the missing resources.

Alternalatalilively you can change your app so that instead of referencing 
files from your CSS-file, you add an inline-stylesheet to your wrapper 
component (or whichever component imports the "bad" stylesheet) and do the 
imports from there, generating the import URL using . But you really shouldn't have to.

As always, It's kind of difficult to assist without knowing or seeing the 
project or setup, but hopefully the suggestions help :).

- hugi


> On 10 Jan 2020, at 17:26, ocs@ocs via Webobjects-dev 
>  wrote:
> 
> P.P.S.
> 
>> On 10 Jan 2020, at 2:54 PM, ocs@ocs via Webobjects-dev 
>> mailto:webobjects-dev@lists.apple.com>> 
>> wrote:
>> I must admit I can't see even what to try now :-O
> 
> Got an idea to override and log out requestHandlerForKey, and the results 
> are... interesting. I thought I'll get the ComponentRequestHandler for those 
> bogus requests; I do not! Instead, far as I can say, it's a 
> WOStaticResourceRequestHandler, which should be all right, far as I 
> understand... could WOStaticResourceRequestHandler ever create R/R loop?!?
> 
> Here's what happens, sanitized and make readable (full log below in case I 
> removed something of importance).
> 
> Any idea what the H. might be happening in there? Me, I'm completely lost :/
> 
> ===
> WorkerThread2 WILLGETHANDLER '_edr_'
> WorkerThread2 DIDGETHANDLER ?NULL?
> WorkerThread2 WILLDISPATCH 
> uri=/cgi-bin/WebObjects/CEBOIS.woa/wo/9UuJz2GsVhmGAeV07uiU2g/2.0.0.9.1.1.1.0.3.1.1
> WorkerThread2 WILLGETHANDLER 'wo'
> WorkerThread2 DIDGETHANDLER 'wo' -> class 
> er.extensions.appserver.ERXComponentRequestHandler
> 
> // R/R loop #3 WorkerThread2 started at 18:09:58.789 10.1. // this is 
> logged out from Application.awake(), this is the normal R/R loop, all right 
> so far
> // request secure false, handler 'wo', WOSID 9UuJz2GsVhmGAeV07uiU2g, 
> IP:127.0.0.1
> // URL: 
> /cgi-bin/WebObjects/CEBOIS.woa/wo/9UuJz2GsVhmGAeV07uiU2g/2.0.0.9.1.1.1.0.3.1.1
> 
> WorkerThread2 WILLGETHANDLER '_edr_'
> WorkerThread2 DIDGETHANDLER ?NULL?
> WorkerThread2 WILLDISPATCH 
> uri=/cgi-bin/WebObjects/CEBOIS.woa/wr/wodata=/Users/ocs/Library/Developer/Xcode/DerivedData/SberDat3-cacbzkicuhqilyfljzgpbaygdgtm/Build/Products/Debug/SberDat3.woa/Contents/Resources/styles.css
>  // normal resource, loaded properly without R/R loop
> WorkerThread2 WILLGETHANDLER 'wr'
> WorkerThread2 DIDGETHANDLER 'wr' -> class 
> com.webobjects.appserver._private.WOResourceRequestHandler
> WorkerThread2 WILLGETHANDLER '_edr_'
> WorkerThread2 DIDGETHANDLER ?NULL?
> WorkerThread2 WILLDISPATCH 
> uri=/dms/css/font-awesome/fonts/fontawesome-webfont.woff2?v=4.6.3
> WorkerThread2 WILLGETHANDLER ''
> WorkerThread2 DIDGETHANDLER ?NULL?
> WorkerThread2 WILLGETHANDLER '_wr_'
> WorkerThread2 DIDGETHANDLER '_wr_' -> class 
> com.webobjects.appserver._private.WOStaticResourceRequestHandler
> 
> // R/R loop #4 WorkerThread2 started at 18:09:59.476 10.1. // this is 
> logged out from Application.awake()
> -IN-sharedEC Created session XARzaDhw1kbKEA8GtBUa70 EC: 
> er.extensions.eof.ERXEC@42bdde17 SEC:  - 18:09:59.481 10.1.20|WorkerThread2 
> // Session constructor log
> 
> WorkerThread2 WILLGETHANDLER '_edr_'
> WorkerThread2 DIDGETHANDLER ?NULL?
> WorkerThread2 WILLDISPATCH 
> uri=/dms/css/font-awesome/fonts/fontawesome-webfont.woff?v=4.6.3
> WorkerThread2 WILLGETHANDLER ''
> WorkerThread2 DIDGETHANDLER ?NULL?
> WorkerThread2 WILLGETHANDLER '_wr_'
> WorkerThread2 DIDGETHANDLER '_wr_' -> class 
> com.webobjects.appserver._private.WOStaticResourceRequestHandler
> 
> // R/R loop #5 WorkerThread2 started at 18:09:59.664 10.1. // this is 
> logged out from 

Re: suspicious sessions and R/R loops created for a CSS font

[Klaus Berkling via Webobjects-dev]

> On Jan 9, 2020, at 10:23 PM, Chuck Hill via Webobjects-dev 
>  wrote:
> 
> Hi OC,
> 
> 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.
> 

This reminds me of relative links to images in WO pages. I overwrote 
dispatchRequest to return an HTTP_STATUS_NOT_FOUND if it the URI wasn’t 
agreeable.

FWIW: https://blog.berkling.us/page1/files/relative_image.html



Klaus Berkling
www.berkling.us  | Photography 





 ___
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

Re: suspicious sessions and R/R loops created for a CSS font

[ocs@ocs via Webobjects-dev]

P.P.S.

> On 10 Jan 2020, at 2:54 PM, ocs@ocs via Webobjects-dev 
>  wrote:
> I must admit I can't see even what to try now :-O

Got an idea to override and log out requestHandlerForKey, and the results 
are... interesting. I thought I'll get the ComponentRequestHandler for those 
bogus requests; I do not! Instead, far as I can say, it's a 
WOStaticResourceRequestHandler, which should be all right, far as I 
understand... could WOStaticResourceRequestHandler ever create R/R loop?!?

Here's what happens, sanitized and make readable (full log below in case I 
removed something of importance).

Any idea what the H. might be happening in there? Me, I'm completely lost :/

===
WorkerThread2 WILLGETHANDLER '_edr_'
WorkerThread2 DIDGETHANDLER ?NULL?
WorkerThread2 WILLDISPATCH 
uri=/cgi-bin/WebObjects/CEBOIS.woa/wo/9UuJz2GsVhmGAeV07uiU2g/2.0.0.9.1.1.1.0.3.1.1
WorkerThread2 WILLGETHANDLER 'wo'
WorkerThread2 DIDGETHANDLER 'wo' -> class 
er.extensions.appserver.ERXComponentRequestHandler

// R/R loop #3 WorkerThread2 started at 18:09:58.789 10.1. // this is 
logged out from Application.awake(), this is the normal R/R loop, all right so 
far
// request secure false, handler 'wo', WOSID 9UuJz2GsVhmGAeV07uiU2g, 
IP:127.0.0.1
// URL: 
/cgi-bin/WebObjects/CEBOIS.woa/wo/9UuJz2GsVhmGAeV07uiU2g/2.0.0.9.1.1.1.0.3.1.1

WorkerThread2 WILLGETHANDLER '_edr_'
WorkerThread2 DIDGETHANDLER ?NULL?
WorkerThread2 WILLDISPATCH 
uri=/cgi-bin/WebObjects/CEBOIS.woa/wr/wodata=/Users/ocs/Library/Developer/Xcode/DerivedData/SberDat3-cacbzkicuhqilyfljzgpbaygdgtm/Build/Products/Debug/SberDat3.woa/Contents/Resources/styles.css
 // normal resource, loaded properly without R/R loop
WorkerThread2 WILLGETHANDLER 'wr'
WorkerThread2 DIDGETHANDLER 'wr' -> class 
com.webobjects.appserver._private.WOResourceRequestHandler
WorkerThread2 WILLGETHANDLER '_edr_'
WorkerThread2 DIDGETHANDLER ?NULL?
WorkerThread2 WILLDISPATCH 
uri=/dms/css/font-awesome/fonts/fontawesome-webfont.woff2?v=4.6.3
WorkerThread2 WILLGETHANDLER ''
WorkerThread2 DIDGETHANDLER ?NULL?
WorkerThread2 WILLGETHANDLER '_wr_'
WorkerThread2 DIDGETHANDLER '_wr_' -> class 
com.webobjects.appserver._private.WOStaticResourceRequestHandler

// R/R loop #4 WorkerThread2 started at 18:09:59.476 10.1. // this is 
logged out from Application.awake()
-IN-sharedEC Created session XARzaDhw1kbKEA8GtBUa70 EC: 
er.extensions.eof.ERXEC@42bdde17 SEC:  - 18:09:59.481 10.1.20|WorkerThread2 // 
Session constructor log

WorkerThread2 WILLGETHANDLER '_edr_'
WorkerThread2 DIDGETHANDLER ?NULL?
WorkerThread2 WILLDISPATCH 
uri=/dms/css/font-awesome/fonts/fontawesome-webfont.woff?v=4.6.3
WorkerThread2 WILLGETHANDLER ''
WorkerThread2 DIDGETHANDLER ?NULL?
WorkerThread2 WILLGETHANDLER '_wr_'
WorkerThread2 DIDGETHANDLER '_wr_' -> class 
com.webobjects.appserver._private.WOStaticResourceRequestHandler

// R/R loop #5 WorkerThread2 started at 18:09:59.664 10.1. // this is 
logged out from Application.awake()
-IN-sharedEC Created session xfFKRWhKfmFYr8YaMRzuc0 EC: 
er.extensions.eof.ERXEC@6b87f93c SEC:  - 18:09:59.668 10.1.20|WorkerThread2 // 
Session constructor log
...
===

etc; essentially the same (i.e., finding the WOStaticResourceRequestHandler 
handler and running an R/R loop) happens twice more.

Thanks and all the best,
OC

Here's the full log for reference, if needed — contains more threads and more 
info for R/Rs, full requests logged out, none of this, I believe, important:

WorkerThread2 WILLGETHANDLER '_edr_'
WorkerThread2 DIDGETHANDLER ?NULL?
WorkerThread2 WILLDISPATCH http://localhost:56005/cgi-bin/WebObjects/CEBOIS.woa/wo/9UuJz2GsVhmGAeV07uiU2g/0.0.0.9.1.3.9],
 upgrade-insecure-requests=[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=/cgi-bin/WebObjects/CEBOIS.woa/wo/9UuJz2GsVhmGAeV07uiU2g/2.0.0.9.1.1.1.0.3.1.1
 defaultFormValueEncoding=UTF-8 formValueEncodingDetectionEnabled=NO 
formValueEncoding=UTF-8 formValues={} >
WorkerThread2 WILLGETHANDLER 'wo'
WorkerThread2 DIDGETHANDLER 'wo' -> class 
er.extensions.appserver.ERXComponentRequestHandler

//
// R/R loop #3 WorkerThread2 started at 18:09:58.789 10.1.
// request secure false, handler 'wo', WOSID 9UuJz2GsVhmGAeV07uiU2g, 
IP:127.0.0.1
// URL: 
/cgi-bin/WebObjects/CEBOIS.woa/wo/9UuJz2GsVhmGAeV07uiU2g/2.0.0.9.1.1.1.0.3.1.1
// allocated: 85 616 176 of: 225 443 840 max: 2 147 483 648 -- 4.0%
//  last R/R: -98 836 144 added to prev 184 452 320
//  free: 2 061 867 472 -- 96.0%
//

//
// R/R loop #3 WorkerThread2 done at 18:09:59.344 took 0.556 s
// allocated: 87 170 

Re: suspicious sessions and R/R loops created for a CSS font

[ocs@ocs via Webobjects-dev]

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 
...") I am always getting the same 
URIs in the requests, they always look like this:

WILLDISPATCH 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  wrote:
> 
> Chuck,
> 
> thanks!
> 
>> On 10 Jan 2020, at 7:23 AM, Chuck Hill > > 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=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 
> ...”, 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 
>>> 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
>>> 
>>> >> 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=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
>>> 
>>> 
>>> 
>>> 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  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 

Re: suspicious sessions and R/R loops created for a CSS font

[ocs@ocs via Webobjects-dev]

Chuck,

thanks!

> On 10 Jan 2020, at 7:23 AM, Chuck Hill  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=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...”, 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 
>>  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
>> 
>> > 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=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
>> 
>> 
>> 
>> 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  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 , so far so 
>> good.
>> 
>> But, if there _is_ an  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