This question is here for visibility only. I have already solved it. Find the answer below.
We setup the following redirect rule, the only redirect rule we had at the time:
RewriteRule "/(.*)(.html)$" "/content/my-company/$1.html" [PT]
As you can see, if I request /en.html, the rule above should rewrite it to /content/my-company/en.html.
Here is the issue we were running into:
if I do the following, in-order, here is what I get at every step:
clear dispatcher cache completely and manually.
request https://example.com/en.html -> returns 404 and the request does not reach the publish server (verified in request.log for publish)
request https://example.com/content/my-comany/en.html - success (200). request reaches publish server AND is now cached in dispatcher under path cache-directory/content/my-comany/en.html
Now if I request https://example.com/en.html from step 1, it returns the page correctly (200). it seems to serve it fro cache?
It seems that dispatcher uses the rewritten url, ONLY if it exists in the dispatcher cache and returns 404 otherwise.
Looking at the adobe docs for dispatcher module here: https://helpx.adobe.com/experience-manager/dispatcher/using/dispatcher-install.html#ApacheWebServerConfigureApacheWebServerforDispatcher
There is an option called DispatcherUseProcessedURL. in our config, it was set to 0 but it should be set to 1 so that the dispatcher module can use the rewritten (processed) url.
That fixed our issue!
Related
I have a web application running on Wildfly 26 that uses SSE broadcasting and works correctly with http. However, when I switch to using an https endpoint, I get Wildfly log entries of:
WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1)
RESTEASY002186: Failed to set servlet request into asynchronous mode,
server sent events may not work
This happens with each registration attempt of the https endpoint but I never see this when registering with the http endpoint.
Testing with curl against the http endpoint results in curl waiting for events to show up (and keeps printing them out as it receives them) until I quit. Using curl to test the https endpoint, I will see the same headers I got from the http endpoint, namely:
HTTP/1.1 200 OK
Connection: keep-alive
Transfer-Encoding: chunked
Content-Type: text/event-stream
But after printing out my registration successful event, curl seems to believe the stream is closed and exits -- giving me my command prompt back.
My #GET MediaType.SERVER_SENT_EVENTS registration endpoint will create an OutboundSseEvent and send it to the SseEventSink to acknowledge successful registration to my SseBroadcaster instance (this is the event curl sees and prints before exiting). I then log a registration successful message before exiting the method. All of this appears to work correctly for both http and https but the stream doesn't stay open once the request endpoint completes because of the failure to run asynchronously as outlined above.
I have not found information on the causes and/or workaround solutions for my RESTEASY002186 problem. I posted a question on this issue last week using the Wildfly Google Group (https://groups.google.com/g/wildfly/c/SO2eHdvMEko) but thought I would try a wider audience since this doesn't seem to be a commonly experienced condition. I don't see any indications during initialization that WildFly will be unable to use asynchronous mode, it just complains when it tries and fails... Any help would be greatly appreciated!
Edit 6/6/2022
The code is running on an isolated network so I can't just cut/paste the code here, but I gutted the resources file to a bare minimum -- just leaving enough for the client to be able to register. The problem remains unchanged. The code is now essentially:
#Path("sse")
public class SseResources {
#GET
#Produces(MediaType.SERVER_SENT_EVENTS)
public void listen(#Context Sse sse, #Context SseEventSink sseEventSink) {
SseRegComplete regComplete = new SseRegComplete("sse-server");
OutboundSseEvent event = sse.newEventBuilder().
name(regComplete.getType().toString()).
id(regComplete.getEventId()).
mediaType(MediaType.APPLICATION_JSON_TYPE).
data(SseRegComplete.class, regComplete).
comment("Event Stream Registration Completed Successfully").
build();
sseEventSink.send(event);
}
}
Before the above simplified code, I had declared the resource as #ApplicationScoped, had Sse injected into it, and kept a reference to the SseBroadcaster so I could use it whenever an event would come in. I was catching the events to broadcast by using an #Observes method (which I also got rid of). I was calling register(sseEventSink) on the SseBroadcaster in the listen method so I could later call broadcast(outboundEvent) whenever I had updates to publish. I got rid of all that just to see if I could get the stream to stay open but to no avail. I still get the RESTEASY002186 message and curl still exits after printing out the regComplete event sent to it in the code above.
Edit 6/7/2022
Yesterday I was able to get my code working in a new vanilla Wildfly 26 install using an https endpoint URL by following these configuration instructions. Something I hadn't mentioned in the original post is that I am trying to add SSE functionality to an already existing app. It is several years old and we actually moved to Wildfly 26 about 6 months ago because of the log4j vulnerability in the earlier version of Wildfly we were using. I suspect that the problem is related to either our Wildfly configuration (perhaps because old settings were brought over that shouldn't have been) or some 3rd party dependency that is preventing Wildfly from using asynchronous mode.
We are using Shiro for authentication and authorization against an LDAP server -- perhaps Shiro has some hooks into the Wildfly runtime that are causing issues? After initial login, we use a session cookie in all subsequent calls. That is a difference from my test server but I don't think it is relevant because the call definitely passed authentication before executing the registration code. The only other thing that comes to mind right now is our web app ships with LogBack and tells Wildfly not to use the default logging framework.
I plan to start today by comparing the two standalone.xml files to see if anything jumps out at me as being fundamentally different. Is there anything else I should be checking for differences (I think there is a domain.xml file somewhere...)?
Edit 6/14/2022
This definitely has something to do with Shiro being in the loop. When I edit the web.xml file to have Shiro's filter-mapping url-pattern to not include the SSE endpoint, everything works as expected.
I have set the /statfileslevel "4" and added headers and enabled TTL . But stat file is not getting generated in the doc root path .
When i send a flush request through the dispatcher flush agent cache ( from Author ACS Commons) is not getting deleted and also could not see any stat file inside the doc root path .
Is there any configuration that needs to be added further .
If you use TTL-based caching on dispatcher then event-based invalidations like page activation or similar is not affecting those resources. So basically resources with cache-control headers are not affected by touching .stat files.
Maybe Delete cache type from ACS flush agent would delete files (included ttl), but not 100%, need's to be tested.
Good example of what and how the enableTTL dispatcher directive is working.
https://github.com/adobe/aem-dispatcher-experiments/blob/main/experiments/enableTTL/README.md
Also very good documentation about caching from adobe.
https://experienceleague.adobe.com/docs/experience-manager-learn/dispatcher-tutorial/chapter-3.html?lang=en#overview
I have a _redirects file in my netlify directory structure
/
- site
-- _redirects
_redirects
https://example.netlify.com/ https://www.example.com/:splat 301!
https://www.example.com/post/196 https://www.example.com/comic/post-name
Problem:
The first redirection occurs successfully, but the 2nd one returns:
Page Not found
I have followed the documentation in https://www.netlify.com/docs/redirects/ but cannot find a cause of this issue.
I note 2 potential causes mentioned in the documentation:
You can also add redirect rules to your netlify.toml file.
^^ I have not tried this, but since it reads "also" I assume using _redirects file should be sufficient.
For Jekyll, this requires adding an include parameter to
config.yml.)
^^ I am not using Jekyll as far as I know, but my project does contain a config.yml file.
You will not be able to chain redirects on Netlify from what the docs read.
The redirect engine processes the first matching rule it finds, so more specific rules should be listed before more general ones
https://example.netlify.com/post/196 https://www.example.com/comic/post-name
/post/196 /comic/post-name
https://example.netlify.com/* https://www.example.com/:splat 301!
You can try without the first line above to see if https://example.netlify.com/post/196 redirects to https://www.example.com//comic/post-name. If it does not redirect, then there is no chaining in Netlify redirects.
Solved by adding:
[[redirects]]
from = "https://www.example.me/post/196"
to = "https://www.example.me/comic/post-name"
status = 200
to netlify.toml
source of solution: https://www.netlify.com/docs/redirects/
Using omnibus gitlab 9.2.
Action: As a non-logged-in user, attempt a request for a public project that doesn't exist (at least not publicly).
Result: Receive a 302 redirect to /users/sign_in from nginx.
What I'd like to see: Receive a 302 redirect to /public (or wherever, for that matter)
What I've tried without success: Adding this to gitlab.rb:
nginx['custom_gitlab_server_config'] = "try_files $uri $uri/ /public;\n\nfastcgi_intercept_errors on;\n\n"
I couldn't find the explicit redirect in any nginx conf, so I guess it's in Rails. I'll peruse that code.
This is actually a custom HA configuration with the gitlab nodes behind haproxy fronts. I thought about possibly doing something on the fronts, but couldn't come up with anything.
Thanks!
Edit:
I see now that replacing the unmatched_route line in routes.rb with:
get '*unmatched_route', to: redirect('/public'), via: :all
does what I need, but I'd of course want to make that change persistent. Is that possible?
My application is directed from http to https. I have security issue to remove the server info in response header. I could see no server info in http response.. but once it is redirected to https, in the response header still the server info exists. how to remove the server info in both the cases... using WAS 6.1,webserver IHS 6.1. any chages to be done in httpd.conf file...thanks in advance...
IHS is an apache based server. To make it less talky about itself you need to add (or modify) a few directives. In short you need to find a line saying ServerTokens and make sure it reads ServerTokens Prod (add the line if it does not exist). ServerTokens reference
Also double check for a line with thte directive ServerSignature. If it does exist it should read ServerSignature Off (which is default) ServerSignature reference
If this is not enough, you can modify the response headers directly. To do that you would need to add a directive like Header unset Server which would remove all response headers with the name Server. Make sure this is what you want though! Header reference
Finally, remember to restart your IHS after you're done with the changes.