I want to generate an array of key-value-paired items and use a looping mechanism to generate a list of content from them in HTML tags format. Is this possible to do it using apache server SSI?
From what I observed, it seems that it is possible to do it using the w3 jigsaw. But I didn't find anything similar for apache and I must use apache.
this is the way that it can be done using the jigsaw:
https://www.w3.org/Jigsaw/Doc/User/SSI.html#loop
Related
I am trying to add unique elements to the lists. I found that there is write flag option ADD_UNIQUE but I failed to make it work using the PHP client. I can not find this option in the list of available options for the appendList method (for example). I am using client for php 7.
Not familiar with PHP - but in Java, I recommend OR-ing 3 flags - ADD_UNIQUE, NO_FAIL and PARTIAL to successfully add unique items to a list.
In my project, there are examples were components uses Server Side directives to say include/exclude components. And few places, proper sightly/JSP code is used for same purpose. For example:
<c:if test="${authorMode}">
<cq:include path="headerpar" resourceType="foundation/components/iparsys"/>
</c:if>
<c:if test="${not authorMode}">
<!--#include virtual="/content/myapp/${lang}/global/customer/header.html"--
</c:if>
From basics I understand Server Side directives gets resolved at Apache itself whereas Sightly/Handlebar codes is processed at Publisher. Is there a benefit of coding using directives? If yes, then pretty much lot of code can be moved to server side scripting since it reduces another layer and Apache is far far faster compared to publisher? Why does Adobe promote their scripts and not promote writing with server side directives?
SSI includes are resolved on apache while cq:include within CQ. Using SSI's require from you a bit more knowledge so you know what you're doing
You can benefit from using SSI includes in many ways (mainly performance-wise as you suggested) if you use it properly.
Assume you have a header and footer that is the same for every page but contains heavy logic (navigation, crx tree traversing etc). In this case, if you properly configure your dispatcher caching the header will actually get rendered only once (for the first page) and if user requests another page that has the same header it will simply be fetched from dispatcher cache
Assuming you have a mainly brochureware page but some components that are dynamic you can also cache parts of the page and deny caching for others - again you have to properly configure your dispatcher
Assuming you have user specific content you could also cache parts of pages and dynamically render only parts of those (that's what Sling Dynamic Include is for -> https://github.com/Cognifide/Sling-Dynamic-Include)
So I would definitely use SSI includes for specific fragments of pages that are reused all across your site or meant to differ for different users, like some headers, footers or sth like "Welcome user 'ABC'". I would though not do that with regular content as it will just be cached within the pages html.
Here is the situation:
I have a number of web servers, say 10. I need to use a (software) load balancer which can be implemented using a reverse proxy server, like HAProxy or Varnish. Now, All the traffic that we serve is over https and not http, so Varnish is out of the question.
Now, I want to divide the users' request into a few categories, which depend on one of the input (POST) parameters of the request. Depending on that parameter, I need to divide the request among the servers, as based on that, (even if all other input (POST) parameters are same) different servers would serve differently.
So, I need to define a custom load balancing algorithm, such that, for a particular value of that parameter, I divide the load to specific 3 (say), for some other value, divide the request to specific 2 and for other value(s), to remaining 5.
Since I cannot use varnish, as it cannot be use to terminate ssl (defining custom algorithm would have been easy in VCL), I am thinking of using HA-Proxy.
So, here is the question:
Can anyone help me with how to define a custom load balancing function using HA-Proxy?
I've researched a lot and I could not find any such document with which we can. So, if it is not possible with HA-Proxy, can you refer me to some other reverse-proxy service, that can be used as a load balancer too, such that it meets both the above criteria? (ssl termination and ability to define a custom load balancing).
EDIT:
This question is in succession with one of my previous questions. Varnish to be used for https
I'm not sure what your goal is, but I'd suggest NOT doing custom routing based on the HTTP request body at all. This will perform very poorly, and likely outweigh any benefit you are trying to achieve.
Anything that has to parse values beyond typical HTTP headers at your load balancer will slow things down. Cookies by themselves are generally a bad idea if you can avoid it.
If you can control the path/route values that is likely a much better idea than to parse every POST for certain values.
You can probably achieve what you want via NGINX with lua scripts (the Kong platform is based on them), but I can't say how hard that would be for you...
https://github.com/openresty/lua-nginx-module#readme
Here's an article with a specific example of setting different upstreams based on lua input.
http://sosedoff.com/2012/06/11/dynamic-nginx-upstreams-with-lua-and-redis.html
server {
...BASE CONFIG HERE...
port_in_redirect off;
location /somepath {
lua_need_request_body on;
set $upstream "default.server.hostname";
rewrite_by_lua '
ngx.req.read_body() -- explicitly read the req body
local data = ngx.req.get_body_data()
if data then
-- use data: see
-- https://github.com/openresty/lua-nginx-module#ngxreqget_body_data
ngx.var.upstream = some_deterministic_value
end
'
...OTHER PARAMS...
proxy_pass http://$upstream
}
}
Is it possible to set a cache-control header communicating with a reverse proxy to ignore query parameters in determining what is a unique uri or in short: validate a cache even if some query parameters have changed?
Sometimes query parameters have nothing to do with the rendering of the page at least from a server side perspective. For instance all utm_* variables from Google Adwords. These are needed for the javascript on your page so you don't want to strip them away and redirect to a cached page but at the same time it would be advantageous not to treat two uri's which are basically the same but have different utm_* parameters as unique when communicating with a reverse proxy.
An example:
http://www.example.com/search?sort=price
http://www.example.com/search?sort=price&utm_campaign=shoes
Is there anyway to tell the reverse proxy using the HTTP 1.1 spec (i.e. some type of http header) that it can just treat these two pages as the same?
You can filter the query string in vcl_recv and there is also a Varnish module for that [1].
Also, you have to keep in mind that query string parameter order matters in this case [2]
See also this related question [3]
[1] https://www.varnish-cache.org/vmod/querystring
[2] http://cyberroadie.wordpress.com/2012/01/05/varnish-reordering-query-string/
[3] Stripping out select querystring attribute/value pairs so varnish will not vary cache by them
suppose the DogManagementPro program is an application written in client/server architecture, where the customers who buys it is supposed to run the server on his own PC, and access it either locally or remotely.
suppose I want to support a "list all dogs" operations in the DogManagementPro REST API.
so a GET to http://localhost/DogManagerPro/api/dogs should fetch the following response now:
<dogs>
<dog>http://localhost/DogManagerPro/api/dogs/ralf</dog>
<dog>http://localhost/DogManagerPro/api/dogs/sparky</dog>
</dogs>
where I want to access it remotely on my local LAN, [the local IP of my machine is 192.168.0.33]
what should a a GET to http://192.168.0.33:1234/DogManagerPro/api/dogs fetch?
should it be:
<dogs>
<dog>http://localhost/DogManagerPro/api/dogs/ralf</dog>
<dog>http://localhost/DogManagerPro/api/dogs/sparky</dog>
</dogs>
or perhaps:
<dogs>
<dog>http://192.168.0.33/DogManagerPro/api/dogs/ralf</dog>
<dog>http://192.168.0.33/DogManagerPro/api/dogs/sparky</dog>
</dogs>
?
some people argue that I should subside the problem altogether by returning just a path element like so:
<dogs>
<dog>/DogManagerPro/api/dogs/ralf</dog>
<dog>/DogManagerPro/api/dogs/sparky</dog>
</dogs>
what is the best way?
I've personally always used non-absolute urls. It solves a few other problems as well, such as reverse / caching proxies.
It's a bit more complicated for the client though, and if they want to store the document as-is, it may imply they also now need to store the base url, or expand the inner urls.
If you do choose to go for the full-url route, I would not recommend using HTTP_HOST, but setup multiple vhosts, and environment variable and use that.
This solves the issue if you later on need proxies in front of your origin server.
I would say absolute URLs created based on the Host header that the client sent
<dogs>
<dog>http://192.168.0.33:1234/DogManagerPro/api/dogs/ralf</dog>
<dog>http://192.168.0.33:1234/DogManagerPro/api/dogs/sparky</dog>
</dogs>
The returned URIs should be something the client is able to resolve.