Site id duplicated in subrequests when we have rewrite rules with _vh_

[cekk]

I have the same problem as #13 and reverted in #14

I have a rewrite rule for one site with "vh" because i need to append a certain string on published url.
Everything works fine, except tiles.

I have some tiles in a view, with the basic data-tile attribute. When Plone tries to render them, plone.subrequest fails because it append the site id twice (siteid/_vh_siteid) in the url.

In my case, the patch proposed by @awello fix the problem, but it seems that breaks other components (like mosaic, that i don't use).

Any idea about how to fix it in a safe way? Or otherwise, any hint about a safe rewrite rule that don't break subrequests?

[cekk]

this is my actual conf.

This is the rewrite rule on apache:

RewriteRule /i($|/+)(.*) http://localhost:7029/VirtualHostBase/https/%{HTTP_HOST}:443/siteid/VirtualHostRoot/_vh_i/$2
ProxyPassReverse /i http://localhost:7029/

I need vh because we need to append "/i/" to the url before Plone routes.
For example calling https://mydomain.com/i/content-id should refer to /siteid/content-id on Plone.

I'm a bit confused about how subrequest should works.
Trying to debug it deeper, i've found that other resources that calls subrequest (like rules.xml from p.a.theming) pass an url like this:

/++theme++my.theme/rules.xml

and subrequest generates a path for subrequest like this:

/VirtualHostBase/https/mydomain.com:443/siteid/VirtualHostRoot/_vh_i//++theme++my.theme/rules.xml

that fetches the right resource.

For tiles the things are different. p.a.blocks calls subrequest passing an url that could be:

• a complete url
• a path (in this case it prepends the site path)

I tried to set both of them to data attribute (data-tile) in my div.
Setting the complete url, p.a.blocks calls subrequest with this url:

https://mydomain.com/i/content-id/@@tile.type/tileid

and generates a path like this:

/VirtualHostBase/https/mydomain.com:443/siteid/VirtualHostRoot/_vh_i/i/content-id/@@tile.type/tileid

on second case (with this path: content-id/@@tile.type/tile_id), p.a.blocks add siteid to the path, and calls subrequest with this url:

/siteid/content-id/@@tile.type/tile_id

that generates a path like this:

/VirtualHostBase/https/mydomain.com:443/siteid/VirtualHostRoot/_vh_i/siteid/content-id/@@tile.type/tileid

both of them are wrong and subrequest can't find the resource.

[ale-rt]

I think I had the same problem expanding tiles and that I ended up with this patch which is project specific:

• https://gist.github.com/ale-rt/f1827ae78fea987fcfd46995304eb811

Of course this is a workaround, I never had the time to submit a proper patch.

[thet]

I also use inside-out hosting with _vh_ parts in the rewrite url for a site with plone.app.blocks with no problems.

The nginx rewrite url like the following:

    location /2018 {
        include /etc/nginx/proxylarge.conf;
        proxy_pass http://VARNISHSERVER:VARNISHPORT/VirtualHostBase/https/DOMAIN:443/PLONEID/LINEAGESUBSITE/VirtualHostRoot/_vh_2018/;
        break;
    }

I do reference my tiles like that:

        <div data-tile="./@@TILENAME" />

I don't have any patches in place and I do not experience any problems.

I use latest Plone 5.1 and use the latest versions of plone.subrequest, plone.tiles, plone.app.blocks, etc.
We do have plone.app.mosaic installed, mainly because of it's main_template implementation for standard browser views.

[cekk]

f**k, the only permutation that i didn't tried: data-tile="./TILENAME"

and it works like a charm! thanks @thet

@ale-rt i know that you are a patchaholic, but i prefer the other solution ;)

[ale-rt]

I would leave the issue open because you do not always want to have tiles relative to the current context.

[cekk]

so do you think that there would be a generic fix to that in the product?

[ale-rt]

I would say that would be the best

[thet]

@cekk for your COMPLETE_TILE_URL and PATH_TO_CONTEXT approach you were calling the tiles from a page template, not? I'm asking because I'm wondering how you construct the url.
I'm using the tiles in a plone.app.blocks layout view, which does not allow for dynamic parts within the template.

[cekk]

Yes, i have a view that could be applied to some content-types that shows tiles in that context.
so the url is something like: http://url_of_the_content/TILENAME/TILEID (i used context.absolute_url() to get the url).
And for the path i tried both /siteid/contentid/TILENAME/TILEID and /contentid/TILENAME/TILEID

[nutjob4life]

I'm seeing this behavior as well whenever I start a site behind VirtualHostRoot/VirtualHostBase/_vh_foo with eea.facetednavigation. The JavaScript to support the faceted display won't load and there's duplicated foo/foo in generated URLs.

The workaround I've been using is to make sure the first request to a page with facets comes from localhost and not from the VHM machinery.

[Rudd-O]

I think I am seeing a related issue with a translated site where each language folder maps to a different domain. The issue is that the content browser to insert images / files / links / related content simply does not load anything, and I know for a fact it is related to VHM and subrequests.

I hope this fixes the problem.

[Rudd-O]

With the latest plone.base, does this problem continue to occur? I can also help repro, but I need detailed repro instructions.