I'm interested in running a graphgist locally, for which there is a script here:
https://gist.github.com/jexp/70296ce410ff431ddbef
I was able to install the modules and run the two tasks but the last line of the script:
open http://localhost:8000/?http%3A%2F%2Flocalhost%3A8000%2Fgists%2Fmy-graph-use-case.adoc
produces an error: Not Found and trying to open the link in the comments:
http://localhost:8000/gists/my-graph-use-case.adoc
causes my browser to download a file for which I have no associated application. has anyone made this work and if so, how?
according to #MichaelHunger the issue is that the default behaviour in Python's SimpleHTTPServer is such that a trailing slash (/) gets added to the end of the url, messing up the request.
according to #PratikMandrekar, in the following article, the problem is that the url as it is in the script does not explicitly specify the file name, forcing the server to redirect to the default. see:
Why does SimpleHTTPServer redirect to ?querystring/ when I request ?querystring?
so after a little experimentation I found this to work:
http://localhost:8000/index.html?http%3A%2F%2Flocalhost%3A8000%2Fgists%2Fmy-graph-use-case.adoc
notice that the colons, slashes, etc. in the inner url must be encoded for this to work
There is a bug/default behavior in simple-http-client that makes it add slashes after query parameters which breaks our app in this case, I have to find a better replacement or fix it.
Perhaps I can also change the rabbithole project to server the graphgist files itself, so that it would be self-contained.
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 made some source+map concatenation and result works in Firefox and Chrome, but does not even request bundle.js.map from webserver in MS Edge and IE11.
Actual JS file is served from http://localhost:8080/bundle.js
bundle.js ends with line:
//# sourceMappingURL=bundle.js.map
Tried both end it with new line and without, does not work in both cases. Is there some checklist to look at or even some "validator"?
Microsoft Edge expects a single sourcemap comment, located at the end of the file. Your file contains two comments, which appears to cause the issue. Remove all but the final comment, and this should resolve the issue for you.
I will file a ticket to track this issue, but it's unlikely we will modify our implementation to accommodate a non-standard use of sourcemap comments. Thank you for bringing this to our attention though. We'll keep watch to see if this affects other users.
I am working with the Build Failure Analyzer plugin for Jenkins. It works fine when I use Plain Text as the Text Source, but when I select Build Log I get an Invalid Url error after clicking Match Text.
The pattern I am using is :
.*no JMeter files matching .* for a Jmeter Project
And the text which I am matching is :
http://localhost:8080/job/Project%20Jmeter/4/
Am I missing something?
Remove %20 in the URL and replace it with blankspace
There are a couple of things that you have to check for this. I'm leaving this for anyone else who might have ran into the same thing that I did. First, you need to ensure that any %20 is a blankspace as previously mentioned, but another one that caught me up is that it is not the URL to the console logs, even through the drop down mentions build log. You are providing a link to the build itself.
You do not seem to have this problem, but it has tripped me up multiple times.
I have a tomcat (7) server running, through which I try to access some public files by http. Some of the files on the filesystem have special characters in them. The ones without those special characters are found. The other ones give a 404. For example:
http://localhost:9090/processed/transcoded/Csángó_TÖMEGKERESZTELŐVEL_EGYBEKÖTÖTT_búcsú_Istensegítsfalvá20111053491309424029417_extracted.mp3"
From what I found out utf-8 in urls shouldn't be a problem. I've tried an url escape function on the filename, which resulted in:
http://localhost:9090/processed/transcoded/Cs%c3%a1ng%c3%b3_T%c3%96MEGKERESZTEL%c5%90VEL_EGYBEK%c3%96T%c3%96TT_b%c3%bacs%c3%ba_Istenseg%c3%adtsfalv%c3%a120111053491309424029417_extracted%2emp3
... but that didn't seem to solve anything either. What to try next? I have no clue what the problem is. Is it maybe related to a Tomcat settings?
Do you have URIEncoding="UTF-8" in your <Connector? If yes, here's what I would do:
create a test webapp which has a filter intercepting all calls to /processed/transcoded/*
place a breakpoint on that filter and see what you get. Does the file name make sense when decoded?
try to open a new java.io.File using this path (obviously prepending local location, e.g. /home/someuser/files/... and assuming the file is there).
I don't think tomcat does much more than what is listed above.
Another alternative would be to debug the Tomcat itself.
Some users of an app of mine are reporting links dont open in the browser. I always launch them with shellexecute(0, 'open', 'http://...
what could I check for an incorrect(?) setting in the http link associations?
You're assuming that the browser registered the open verb. It may not have done so.
Just pass nil as the second parameter and omit the open, and let the OS determine what the default action is for the http:// protocol, and you should be fine.
Sounds like the default browser is not functioning quite right. I guess the first thing I would try is to have them enter an (any) url into start->run and see if that pops up.
You could also have them register what the settings on the URL below are:
http://russenreaktor.wordpress.com/2010/07/01/solved-fix-default-protocol-http-association-in-windows/
Or use the ftype utility on the cmdline:
C:\Users\marco>ftype http
http="C:\Program Files (x86)\Internet Explorer\iexplore.exe" -nohome
These operate on registry keys under HKEY_CLASSES_ROOT/protocolname with protocolname=http/ftp etc.
Making a simple app to dump these keys might help finding out what the pattern here is.
FYI, this failure can be dynamic -- i.e., the old MS PhotoEditor would block opening URLS using ShellExecute. (C.f., http://code.activestate.com/recipes/334665/ ). Fix is as noted in the recipe: write out an .HTML file and shellexecute that.