[x3d-public] X3DOM dev url changed, HTML invocation

John Carlson yottzumm at gmail.com
Tue Jul 15 20:23:46 PDT 2025 

I think one advantage of using a Java Web Server is that it has access to
certificates in cacerts file in the Java distribution (maybe Jakarta now).
It’s a messy job to add certificates there, and you have to know the
default password.   The biggest problem might be getting the changes past
configuration management.

No guarantees, but you should be able to get Java https working this way
for your site.

As of 13 years ago.  I gave up on Java server-side a long time ago.

I do think localhost is already in cacerts.

Make backups in case you mess up.

John

On Tue, Jul 15, 2025 at 9:57 PM Don Brutzman via x3d-public <
x3d-public at web3d.org> wrote:

> Thank you very much for helpful information.
>
> It sounds like a careful reading of the CORS related specification will be
> appropriate. We might need to poke the web browsers themselves (and W3C)
> if they are not implementing consistently.
>
> If we are not successful getting the same treatment as HTML itself, then
> more work is needed.  Right now we have a handful of inconvenient/contorted
> workarounds… we will need to strive for some sort of consistency for best
> practices that are making it _easy_ for regular developers and plain old
> web users to get work done.
>
> The challenges keep morphing, we can rise to meet them. Onward we go.
>
> all the best, Don
>
> --
> Don Brutzman
> X3D graphics, virtual worlds, Navy robotics
> https://faculty.nps.edu/brutzman
>
>
> On Tue, Jul 15, 2025 at 13:44 Andreas Plesch via x3d-public <
> x3d-public at web3d.org> wrote:
>
>> Hi Don,
>>
>> The images and the relative url are completely legal. The problem is the
>> file:// protocol which is not compatible with CORS in general. The simplest
>> solution is to just run a small httpd server (node, python, java:
>> https://docs.oracle.com/en/java/javase/21/docs/specs/man/jwebserver.html
>> ) and use https://localhost . There then is no CORS setup needed. This
>> is actually development which is closer to deployment because then both use
>> a http server.
>>
>> x3dom can catch the exception but cannot make it ok for the web browser
>> to load the image file anyway. Unfortunately, it is the web browser which
>> may be seen as overzealous.
>>
>> Apparently, chrome has a flag to disable CORS checking (not tested):
>>
>>
>> https://medium.com/@beligh.hamdi/run-chrome-browser-without-cors-872747142c61
>> https://blog.christopherhoelter.com/disable-cors-checks-chrome
>>
>> Similarly, firefox has a config option which persists (tested, worked for
>> me):
>>
>> https://www.devdude.com/disable-cors/
>>
>> Hope this helps, -Andreas
>>
>>
>>> Message: 1
>>> Date: Tue, 15 Jul 2025 11:00:29 -0700
>>> From: Don Brutzman <don.brutzman at gmail.com>
>>> To: "Extensible 3D (X3D) Graphics public discussion"
>>>         <x3d-public at web3d.org>
>>> Cc: "vmarchetti at kshell.com" <vmarchetti at kshell.com>,
>>>         x3dom-developers at lists.sourceforge.net
>>> Subject: Re: [x3d-public] X3DOM dev url changed, HTML invocation
>>>         questions
>>> Message-ID:
>>>         <CABx5f7eezsn1LURQft==ECQ85OZ3hmHqLSrWb7YNh6_VhPy=
>>> 9Q at mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Interesting... I pulled down a fresh copy of Firefox and tested there as
>>> well.  Once again, no images loaded into the X3DOM scene.
>>>
>>> These images should be legal and allowed by X3DOM, they are in a direct
>>> subdirectory beneath the X3DOM page in question.  They would be allowed
>>> in
>>> any other HTML page.
>>>
>>> Possible approach: perhaps x3dom.js can catch the exception and treat it
>>> as
>>> OK, when appropriate?   The following debugger screenshot from Firefox
>>> hints at that possibility, i.e. "Uncaught DOMException"
>>>
>>> [image: image.png]
>>>
>>> (Opinion: running a local CORS server is of course a workaround, but that
>>> means development/testing with a difference setup than deployment,
>>> slowing
>>> efforts and introducing other potential issues.  So relaxing this
>>> overzealous restriction on local content loading local content seems
>>> worthwhile.)
>>>
>>> all the best, Don
>>>
>>> On Tue, Jul 15, 2025 at 4:40?AM vmarchetti--- via x3d-public <
>>> x3d-public at web3d.org> wrote:
>>>
>>> > I think these errors are a result of web browser configuration or
>>> policy
>>> > rathen than a change in the x3dom code.
>>> >
>>> > I am seeing the reported problem in loading ImageTexture resources from
>>> > the local file system in my install of Chrome, but not in Firefox. That
>>> > leads me to think it's a difference in how each browser is
>>> interpreting the
>>> > security risk of reading a local file through an XHR request, an issue
>>> > related to the CORS specification.
>>> >
>>> > Vince Marchetti
>>> >
>>> > On Jul 14, 2025, at 9:08?PM, Don Brutzman via x3d-public <
>>> > x3d-public at web3d.org> wrote:
>>> >
>>> > Thank you Andreas.  I have
>>> >
>>> >    - taken out the CSS for SANS, SERIF, TYPEWRITER
>>> >    - updated the node-list url,
>>> >    - tested both updated addresses for x3dom-full.js
>>> >
>>> > Here are two examples using your preferred address:
>>> >
>>> >    -
>>> >
>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/Animation/BoxSwitchX3dom.xhtml
>>> >    -
>>> >
>>> https://www.web3d.org/x3d/content/examples/X3dForAdvancedModeling/Animation/RotationCalculatorExampleX3dom.xhtml
>>> >
>>> > However, a problem has emerged.  Neither model is displaying image
>>> > textures when launched on local host.
>>> > ERROR: [Utils|createTexture2D] Can't http request:
>>> images/WhiteImage.png
>>> > ERROR: [Utils|createTexture2D] Can't http request:
>>> images/YellowImage.png
>>> > ERROR: [Utils|createTexture2D] Can't http request:
>>> > images/TurquoiseImage.png
>>> > ERROR: [Utils|createTexture2D] Can't http request:
>>> images/GreenImage.png
>>> > ERROR: [Utils|createTexture2D] Can't http request: images/GreyImage.png
>>> > ERROR: [Utils|createTexture2D] Can't http request: images/RedImage.png
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > <image.png>
>>> >
>>> > Hopefully this is a fixable issue, TIA for any scrutiny.  This was a
>>> very
>>> > useful capability when invoking the original
>>> > https://x3dom.org/download/dev/x3dom-full.js
>>> >
>>> > all the best, Don
>>> >
>>> > On Sun, Jul 13, 2025 at 8:45?PM Andreas Plesch <
>>> andreasplesch at gmail.com>
>>> > wrote:
>>> >
>>> >> Answers below.
>>> >>
>>> >> On Sun, Jul 13, 2025 at 2:21?PM Don Brutzman <don.brutzman at gmail.com>
>>> >> wrote:
>>> >>
>>> >>> Andreas writes on 10 JUL 2025:
>>> >>>
>>> >>>> I have deployed a new dev version.
>>> >>>> Please note that the download link for the dev version of x3dom has
>>> >>>> migrated from x3dom.org/download/dev (not updated) to
>>> >>>> https://cdn.jsdelivr.net/gh/x3dom/x3dom-dev/dist/x3dom.js
>>> (preferred)
>>> >>>> or
>>> >>>> https://x3dom.github.io/x3dom-dev/dist/x3dom.js
>>> >>>> which is
>>> >>>> automatically updated through
>>> >>>> https://github.com/x3dom/x3dom-dev
>>> >>>> for every merged PR at
>>> >>>> https://github.com/x3dom/x3dom
>>> >>>> The netlify link is obsolete.
>>> >>>
>>> >>>
>>> >>>> Andreas
>>> >>>
>>> >>>
>>> >>> Thanks for the alert.  I am hoping to get the address and invocation
>>> >>> correct in our X3D Example Archives scenes by updating the conversion
>>> >>> stylesheet.
>>> >>>
>>> >>>    - X3D Example Archives
>>> >>>    -
>>> >>>
>>> https://www.web3d.org/x3d/content/examples/X3dResources.html#Examples
>>> >>>    -
>>> >>>
>>> https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/X3dToX3domX_ITE.xslt
>>> >>>
>>> >>> The X3dToX3domX_ITE.xslt stylesheet produces the following header in
>>> >>> these examples:
>>> >>>
>>> >>>    - X3D Example Archives: X3D4WA, X3D for Web Authors, Chapter 01
>>> >>>    Technical Overview, Hello World
>>> >>>    -
>>> >>>
>>> https://www.web3d.org/x3d/content/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloWorldIndex.html
>>> >>>    -
>>> >>>
>>> https://www.web3d.org/x3d/content/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloWorldX3dom.xhtml
>>
>> --
>> Andreas Plesch
>> Waltham, MA 02453
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250715/13bda5f9/attachment.html>

More information about the x3d-public mailing list