Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Locker image + BaseRewriteURL

Updated to 15.1.3 and running as a service with reverse proxy.   The new SVG locker image logic looks to break if you are using BaseRewriteURL.  If I use BaseRewriteURL I get a 404 on 'loading_svg.svg', without using BaseRewriteURL the image locker displays fine.

Do you mean that you are setting URLBase property at design/runtime? Or, are you using OnRewriteUrl event?
Using the OnRewriteUrl event (I found a workaround so it's not critical).
Are you using a custom image or changed anything from the standard locker? I can't recreate this issue at all.
Using the standard locker (working in 15.0.20).

If I use BaseRewriteURL like so and proxy through Abyss:


void __fastcall TIWServerController::IWServerControllerBaseRewriteURL(THttpRequest *ARequest,
          UnicodeString &ARewriteURL)
  ARewriteURL = "/DFWPE";

I get:

Edge -
HTTP404: NOT FOUND - The server has not found anything matching the requested URI (Uniform Resource Identifier).
GET -$/gfx/loading.gif

Chrome -
DFWPEForm.html:687 GET$/gfx/loading_svg.svg 404 (Not Found)

One odd thing is Edge is looking for a gif but Chrome is looking for the svg.

If I comment out 'ARewriteURL =' and don't proxy then all works as expected.

My temporary workaround was to create the path '/dfwpe/$/gfx/' under the Abyss root with the gif+svg files, they are then pulled correctly while proxying.
This seems to be the issue:
  • Note the upper case of the ARewriteURL value '/DFWPE'.
  • The locker url translates ARewriteURL to lower case -$/gfx/loading_svg.svg
If I change the locker url to$/gfx/loading_svg.svg then it correctly serves the file.  I checked some of the other internal file url's and the original ARewriteURL case is preserved.
You are probably using Apache as a reverse proxy, correct?

We will get it fixed in the next release.

Forum Jump:

Users browsing this thread: 1 Guest(s)