I'm working on a rather large legacy web app with the following stack: nginx, Django, React with React Router.
My problem is that any URL that I load gets a # appended to one before end if the last char is a /.
So https://dev.local/feed/ becomes https://dev.local/feed/#/,
and https://dev.local/create/?fid=user8:13/ becomes https://dev.local/create/?fid=user8:13#/.
I've investigated everything on the front end side. I'm using browserRouter, not hashRouter. I only have one router in my front end. I suspect this is coming from the back end, but not ruling out the front end. Edit: tried completely commenting out the router - the problem persists.
My question is how do I generally approach debug something like this? Browser debug tools - console, network, etc are not showing any redirects or URL rewrites. What would work here?
The issue disappeared after I ripped out a large node module with a lot of subdependancies (old version of spectacle). The list of subdependencies is quite extensive, and it's hard to pinpoint what solved the problem. Nothing obvious could be seen, like multiple version of react-router or history modules.
Related
We are currently moving an EE6 / JSF application from a deployment path someserver.com/app to its own subdomain app.someserver.com.
Most things are working smoothly, but we have had unexpected troubles with how the web layer handles the now basically nonexistent context-root.
One thing we found and fixed early was that a cookie we set had its path shortened from "/app" to "", and thus was only readable per folder on the server, not for the entire application.
We have now found a similar problem with hyperlinks that we generate in JSF:
Go to home page
This was previously rendered as href="/app" and worked fine, but now with href="" the link is understandably no longer active. I want it to say href=""/".
Is there an elegant solution for that?
Keep in mind that we also have links of the form
Go to projects page
, so simply replacing the empty context path with "/" is not good enough.
Am I missing something obvious? I saw an explanation here (which matches what we experience), but no elaboration on possible solutions.
Turns out I wasn't thinking clearly. I was so focused on fixing the string that #{request.contextPath} produces, that I missed that I basically used it wrong the entire time.
The simplest solution is to just use
...
(with a trailing slash) to get to the root of the application, and never use href="#{request.contextPath}" without a slash at all.
This solves both cases. If the application is deployed to "some_folder", the link becomes "some_folder/". And if the application is deployed to the server root, then the link becomes "/".
Hope this helps someone who stumbled into the same trap.
I just encountered a strange behaviour in my current RoR web app: every time I use the browser's back button (multiple browsers tested, safe mode included), the GET request is being sent multiple times, duplicated. Sometimes twice, but up to 5 times in a row in under 3 seconds. This also causes the SQL queries to run multiple times, doing the same thing.
If I use links to go back, or paste URLs to access the previous page, this does not happen.
Did anyone encounter this, or know what could cause it?
Thanks for your help!
Best,
Alex
Although I've found this to be caused by other issues, the main cuprit is Turbolinks.
Basically, Turbolinks loads the body of your new view via ajax, instead of pulling the whole page (it's meant to speed up the application in production).
It's often the case that Turbolinks will cause issues such as duplicate requests when pressing the back button etc... although to get it with every browser is very strange.
--
Due to a lack of code, I can only speculate on this issue.
It's probably wrong, but a good test to see if it replicates is to remove the references to turbolinks in your JS files; specifically:
#app/assets/javascripts/application.js
//= require turbolinks <- remove this line and see if it fixes the issue
I'll happily delete the answer if it's inappropriate. You'd be best putting up a public repo so that people can see what infrastructure you have.
For me, I realised that the issue was caused by javascript_include_tag out of head tag in aplication.html.erb.
After moving to correct place (inside head tag, right after stylesheet_link_tag) the multiple requests was gone!
We're (me, a colleague and an outsourced dev) building an iOS webDav navigation App which we believe is having trouble validating a URL.
We're accessing a webdav server via the app. One of servers which is https://webdav.microdigit.org.uk/test/ works perfectly.
However our main server which is https://vpn.westbuckland.devon.sch.uk/webdav/ doesn't work.
It seems to be due to the extra dot in the URL but we're not sure.
This is our current expression:
NSString *myregex = #"\\bhttps?://[a-zA-Z0-9\\-.]+(?::(\\d+))?(?:(?:/[a-zA-Z0-9\\-._?,'+\\&%$=~*!():#\\\\]*)+)?";
It just seems odd that the app will connect to a standard length URL such as https://vpn.something.com/ or even starting from a subfolder such as https://vpn.something.com/webdav/
You can then go one more and add another "dot" to the URL such as https://vpn.something.org.uk/webdav
However when you go one further it will connect to https://vpn.something.edu.org.uk/webdav/ but when you start trying to load a file or navigate the file structure, it reports a 404 in the debugger as if the files are not found.
Is it the extra dot in the URL? It seems to be the only thing we can think of. Our outsource dev has been pretty good so far in debugging most of our code (which was a purchased fully licensed base) but we're now reaching the end of the road. If anyone believes it is the regex expression. What would someone recommend we use instead?
I have a perfectly working admin backend on my dev environment but it fails miserably on the prod environment. Specifically a bunch of problems arise :
It is unable to read the symfony/web/sf/ directory hence not loading the required images though it states that a project has been successfully created. This however is not the case with the frontend leading me to believe that the problem is more sinister than what meets the eye.
Though it loads the admin pages, the css is not loaded, even though admin.css is present in the web/css directory.
I did an inspect element and the problem seems to be this, instead of routing to
/web/css or /sfDoctrinePlugin or /web/js
it prefixes the name of the app [controlcenter in my case] to everything, essentially rendering the HTML as:
href = "/controlcenter/web/css" or href = "/controlcenter/js" or href = "/controlcenter/js" . And this does not happen at all on my dev environment and things render the way they do.
Fixits anyone?
This was completely ridiculous of me to post this. I was simply trying to go to controlcenter/module which basically translates to backend/module for most people.
The index file in this case is controlcenter.php, and upon accessing that, I get the website to render the way it ought to. Sorry for the confusion people. Hopefully someone drops in by and sees the answer for themselves.
I should set up defaults in my routing.yml so that it automatically redirects without me having to type controlcenter.php
Thanks
A website of mine is behaving weirdly. The layout sometimes is fine, and sometimes it is screwy. An example page that I see the problem on is this one: link
Disclaimer: I have yet to start my investigation into cause in earnest. I am turning to Stackoverflow because I am lazy and I hope someone will say "That happened to me once, it is probably this...". So please, no one get stuck into this working out this issue if it is something you have never seen before, as it wouldn't be fair as I have not done it myself.
Ok, some background:
The problem usually (maybe always) occurs when first viewing the page
The problem does not show up always, only sometimes
When the page shows up munged, if you refresh it usually reloads looking as it should
The site is a rails app
The css is passed through the neat Smurf Gem, which automatically minifies the CSS and Javascript on the page.
The layout problems happen in firefox (both linux and winXP)
The CSS is served up in the production environment using the ":cache => true" option which concatenates all the css files into one file
Anyway, I am hoping that this has happened to someone before and it will be really simple to fix. If not, I'll go and investigate and return with the solution (or a request for more help).
Thanks in advance!
James.
[edit]I added the first two bullet points, inspired by the comments and first answer[/edit]
We have had something similar when using HAML and SASS that resulted in the CSS being completely unavailable. It only happened on deploys. We determined it was a combination of the Rails stylesheet merging and the generation of the CSS from SASS. Sass was not done generating the CSS, which it did so on the first request to the application, when Rails attempted to merge it all together. The result, a corrupt useless CSS file. Then we stumbled upon this article which has a solution for preventing this issue.
Based on all this, my best guess is that the Smurf gem is attempting to generate your file on the first request, but Rails is serving it out before its done. The generation completes then each following request is fine. If this is the problem then the only solution i know of is to get the file generated before the first request. Of course, this does assume that it is related to deployments or application restarts in some way.
Peer
I had such a problem. The problem was only at the first time the page was loaded. Just reload it and it was fine.
The problem in my case was that the images where not there in the cache for the first time so the browser didnt know it's dimensions when preparing the page which caused the problem
If an image doesn't have a height/width assigned to it, a place is created on the page and it's put there. If the image doesn't quite fit, the browser may not know this until it's refreshed. Then it already knows the size and can properly fit it onto the page.