[product/ERP5Type] Support wildcart in VirtualHostMonster
-
@jerome We got this patch merged in Zope : https://github.com/zopefoundation/Zope/pull/318 I need to update OfficeJS Appstore Serveur asap, JP said me to merge this patch, we could reverts this commit when Zope make a new release ? Or should i use a temporary erp5 branch for this project ?
-
Owner
https://github.com/zopefoundation/Zope/pull/318 is for zope master branch, which is for 4.x releases, but we are using 2.13.x releases, so the best would be to have this patch in 2.13 branch and have zope guys make a 2.13 release that we can use.
For the IPv6 support, we did https://github.com/zopefoundation/Zope/pull/314 for master branch and then backported it 2.13 branch in https://github.com/zopefoundation/Zope/pull/395 and we are now waiting for someone in zope to make a release and then we'll use the new zope release in slapos. But in the ipv6 case, it's not really urgent, so it's no problem to wait.
So the point is that even if we have https://github.com/zopefoundation/Zope/pull/318 accepted to be able to use it, we would need:
- make another PR to backport on zope 2.13 branch
- wait for zope to make a release
- update ERP5 software release in slapos repository to use the new version of Zope egg
which will take time (especially zope maintainers seems more interested about porting zope to python3 in 4.x branch than to make releases on 2.13 which is a "stable" branch )
In the meantime, I (but it's just me) would prefer that we don't have a monkey patch (we already have so much and it's always causing problems - here for example if we apply this monkey patch, when we update zope we won't have the IPv6 support). Is it possible to use a temporary branch for officejs ? this seem the fastest solution.
Or ... we never discussed this, but maybe this does not need a patch so low level, it's possible to call
request.setVirtualRoot
andrequest.setServerUrl
at a higher level, in traversal hook or using an access rule -
Owner
Or this can be a patch in the software release, like we do for now in slapos!377 ? (cc @rafael )
or this can be integrated in frontend ? If I understand correctly, it can be a variation of the zope frontend type that instead of rewriting:
host.domain.com/(.*) => ^/VirtualHostBase/https//host.domain.com:443/VirtualHostRoot/path/$1
would rewrite to
([a-zA-Z]*).domain.com/(.*) => ^/VirtualHostBase/https//host.domain.com:443/VirtualHostRoot/path/$2/$1/
maybe @luke knows this ?
It's hard for me to comment because I don't really understand the need for this patch. Is this done with @romain ?
-
mentioned in merge request slapos!377
-
Owner
Explicitly on the apache or just on the backend ? if we need flexibility it might be better to do it on zope and we already have a patch to do it on zope.
What annoys me is that I'm discussing this, but I still don't really understand the reasons for this patch.
I looked a bit more closely and I think it's just about doing
([a-zA-Z]*).domain.com/(.*) => ^/VirtualHostBase/https//$1.domain.com:443/VirtualHostRoot/path/$2
so that the hostname is preserved ( note that
[a-zA-Z]
part of the regex is a bit simplified ). The test tests with path, but this is just intended to set hostname, is it ?Then, what's the need for flexibility ?
-
mentioned in merge request officejs-appstore!10 (closed)