Just wondering what could the problem be why I can't access jquery ui autocomplete folder in the prod side.
I've been using this widget in the dev side and it works perfectly. However, when I deployed it, I get errors saying, jquery.ui.core.js, jquery.ui.widget.js, jquery.ui.position.js, jquery.ui.all.css, and jquery.ui.autocomplete.js cannot be found: "404 Object Not Found".
This is how I reference these files:
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js"></script>
<script type="text/javascript" src="/folder1/folder2/jquery-ui-1.8.10.custom/development-bundle/ui/jquery.ui.core.js"></script>
<script type="text/javascript" src="/folder1/folder2/jquery-ui-1.8.10.custom/development-bundle/ui/jquery.ui.widget.js"></script>
<script type="text/javascript" src="/folder1/folder2/jquery-ui-1.8.10.custom/development-bundle/ui/jquery.ui.position.js"></script>
<script type="text/javascript" src="/folder1/folder2/jquery-ui-1.8.10.custom/development-bundle/ui/jquery.ui.autocomplete.js"></script>
<link rel="stylesheet" href="/folder1/folder2/jquery-ui-1.8.10.custom/development-bundle/themes/base/jquery.ui.all.css">
Using Firebug, these are the Response and Request headers respectively:
HTTP/1.1 404 Object Not Found
Server: Microsoft-IIS/5.0
Date: Thu, 14 Apr 2011 08:22:27 GMT
Connection: close
Content-Length: 4040
Content-Type: text/html
GET /folder1/folder2/jquery-ui-1.8.10.custom/development-bundle/ui/jquery.ui.core.js HTTP/1.1
Host: (hostname)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: (referrer)
Cookie: (cookies)
I'm using Coldfusion MX 6.1. Are there permission or hosting issues involved? I don't have any idea here. Please help. Thanks.
When you use "/" before your src addresses, you are actually telling that the "folder1" is located in the root folder of your web server (i.e. WWW in Apache)
So if "folder1" is simply a folder located in the same path that your code file is, you should use:
src="folder1/folder2/jquery-ui-1.8.10.custom/development-bundle/ui/jquery.ui.core.js"
I got this working, at last. What I did was I got all folders outside of jquery-ui-1.8.10.custom folder. That is, instead of /folder1/folder2/jquery-ui-1.8.10.custom/development-bundle/ui/jquery.ui.core.js, I now have /folder1/folder2/development-bundle/ui/jquery.ui.core.js.
I still don't get why the folder name jquery-ui-1.8.10.custom can't be found. If anyone knows why please tell me. Thanks!
Related
I've been trying to trigger a build via the Jenkins API so far with no success. I configured a job on 'Trigger builds remotely' and set a token, 'abc'.
Then in postman I did a post to:
$jenkinsurl:$port/job/$jobname/build?token=abc
And the response is:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<title>Error 403 No valid crumb was included in the request</title>
</head>
<body>
<h2>HTTP ERROR 403</h2>
<p>Problem accessing /job/DCD%20Specifications/build. Reason:
<pre> No valid crumb was included in the request</pre>
</p>
<hr>
<i>
<small>Powered by Jetty://</small>
</i>
<hr/>
</body>
I also tried to use basic authentication with a valid username and password, but to no avail.
I can use gets to retrieve whatever information I want from the Jenkins API just fine; it's only this post that gives me this problem.
I had Jenkins 2.7 and updated to 2.19.4 and both versions give me this problem. What am I doing wrong here?
Pass in POST headers, "Jenkins-Crumb:5740ac1b614ca59f5dd5ef151b2895b3".
Your Crumb can be obtained from the URL http://jenkins:8080/crumbIssuer/api/xml
In the POST body, use the appropriate Jenkins XML API request.
Here is my Postman images with parameters:
This worked for me:
Obtain crumb
$ wget -q --auth-no-challenge --user yourUserName --password yourPassword--output-document - 'http://myJenkins:8080/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,":",//crumb)'
Now run the Jenkins job
$ curl -I -X POST http://yourUserName:yourPassword#myJenkins:8080/job/JOBName/build -H "Jenkins-Crumb:44e7038af70da95a47403c3bed5q10f8"
HTTP/1.1 201 Created
Date: Fri, 28 July 2017 09:15:45 GMT
X-Content-Type-Options: nosniff
Location: http://myJenkins:8080/queue/item/17/
Content-Length: 0
I've website at http://revoniaga.com which is run RoR but the font won't load where it said "blocked from loading by Cross-Origin Resource Sharing policy". It cause by Amazon CloudFront. I've try everything but still same result.
First, I put my font assets under /app/assets/font
then in my css (vendor/assets/stylesheets/font-awesome.css), I use something like this:
#font-face {
font-family: 'FontAwesome';
src: url('/assets/fontawesome-webfont.eot?v=4.3.0');
//and so on for other font format
}
At my /etc/nginx/sites-available/revoniaga_production, I put
location ~* \.(eot|otf|svg|ttf|woff|woff2)$ {
add_header Access-Control-Allow-Origin *;
}
Then when I curl:
curl -I https://d3bkb7gt2ds4m6.cloudfront.net/assets/fontawesome-webfont.woff2
It said
HTTP/1.1 404 Not Found
Content-Type: text/html
Content-Length: 168
Connection: keep-alive
Server: nginx/1.6.2
Date: Wed, 18 Mar 2015 09:34:29 GMT
Age: 242
X-Cache: Error from cloudfront
Via: 1.1 404e3b476748051f3f9bc690b72173b4.cloudfront.net (CloudFront)
X-Amz-Cf-Id: 3yUNjkFQHC83FlbEwVMBSddpQND_4GbXauyeTtDyKawS6GzftUwXRA==
I'm also restarting my server "service nginx restart" but still nothing happen
Here is my CloudFront which is the default setting
Everything work fine in my dev env
I couldn't figure why this happening. Please help
Thanks in advance
Problem solved by clean install the server, upgrade ruby to 2.2.1 plus.. looks like the issue come from the server itself. my setting before was fine..
I've got a rails app hosted on Heroku for which I'm trying to update the robot.txt file.
The local file, which is at /public/robots.txt, reads:
User-agent: *
Disallow: /admin/
However when I deploy the app to Heroku, the robots file is seemingly not updated. The remote version reads:
# See http://www.robotstxt.org/wc/norobots.html for documentation on how to use the robots.txt file
#
# To ban all spiders from the entire site uncomment the next two lines:
User-agent: *
Disallow: /
The live url is at http://www.cowboypicks.com/robots.txt.
Running curl -I http://www.cowboypicks.com/robots.txt yields:
HTTP/1.1 200 OK
Age: 2317078
Cache-Control: public, max-age=2592000
Content-length: 200
Content-Type: text/plain
Date: Wed, 30 Apr 2014 17:01:43 GMT
Last-Modified: Thu, 03 Apr 2014 14:21:08 GMT
Status: 200 OK
X-Content-Digest: 10c5b29b9aa0c6be63a410671662a29a796bc772
X-Rack-Cache: fresh
Connection: keep-alive
Indicating the file hasn't been updated since 3 April, however it has been updated today (30 April). Even stranger, when I run heroku run bash followed by cat public/robots.txt I get:
User-agent: *
Disallow: /admin/
Indicating the file is being updated on Heroku but it's showing an older (I assume cached) version for some reason. There is some caching on the app using dalli/memcache, but I wouldn't have thought that would affect static files? Any ideas on how I could further debug the problem?
It turned out that Dalli had indeed been caching the robots.txt file in production. The expiry date was set in production.rb with the line:
config.static_cache_control = "public, max-age=2592000"
Running the following from the rails console flushed the cache and sorted the problem:
Rails.cache.dalli.flush_all
I am deploying my RESTful web application on jBoss EAP 6.1 (7.2.1Final) with Wink 1.2 and getting following exception on all the request;
<b>JBWEB000070: exception</b>
<pre>java.lang.NullPointerException
org.apache.wink.common.internal.http.Accept.valueOf(Accept.java:139)
org.apache.wink.server.internal.contexts.HttpHeadersImpl.getAcceptHeader(HttpHeadersImpl.java:152)
org.apache.wink.server.internal.contexts.HttpHeadersImpl.getAcceptableMediaTypes(HttpHeadersImpl.java:106)
org.apache.wink.server.internal.registry.ResourceRegistry.filterByProduces(ResourceRegistry.java:558)
org.apache.wink.server.internal.registry.ResourceRegistry.filterDispatchMethods(ResourceRegistry.java:482)
org.apache.wink.server.internal.registry.ResourceRegistry.findMethod(ResourceRegistry.java:359)
org.apache.wink.server.internal.handlers.FindResourceMethodHandler.handleResourceMethod(FindResourceMethodHandler.java:138)
org.apache.wink.server.internal.handlers.FindResourceMethodHandler.handleRequest(FindResourceMethodHandler.java:65)
org.apache.wink.server.handlers.RequestHandlersChain.handle(RequestHandlersChain.java:26)
org.apache.wink.server.handlers.RequestHandlersChain.handle(RequestHandlersChain.java:22)
org.apache.wink.server.handlers.AbstractHandlersChain.doChain(AbstractHandlersChain.java:63)
org.apache.wink.server.internal.handlers.FindRootResourceHandler.handleRequest(FindRootResourceHandler.java:95)
org.apache.wink.server.handlers.RequestHandlersChain.handle(RequestHandlersChain.java:26)
org.apache.wink.server.handlers.RequestHandlersChain.handle(RequestHandlersChain.java:22)
org.apache.wink.server.handlers.AbstractHandlersChain.doChain(AbstractHandlersChain.java:63)
The same application works OK on previous versions of jBoss like EAP 5.1 and old.
I have also captured the posted request using tcpmon and getting following information in headers;
GET /hothouse-iris/Hothouse.svc/ HTTP/1.1
Host: 127.0.0.1:9090
Connection: keep-alive
Authorization: Basic U1NPVVNFUjE6MTIzNDU2
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36
Content-Type: application/atom+xml
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Cookie: JSESSIONID=8D9FE5379FE7576610BB4B78A431AD10; __utma=96992031.2145502422.1381922298.1382004674.1382006170.4; __utmc=96992031; __utmz=96992031.1381922298.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
I am using Chrome extension POSTMan to request my service and it works.
The problem is that initialization of Accept class does not actually happen, and the delegate field is null.
The RuntimeDelegate is an interface whose implementation should be specified in META-INF/service/javax.ws.rs.ext.RuntimeDelegate file which is searched on the class path.
wink-common.jar contains such a service file with the correct class name of the implementation but if some other service file with the same name is found on class path (on of the jars) before the correct one, we will have such a weird behavior.
The problem was that JAX-RS implementation provided by jboss 7 was conflicting with Apache Wink, we had to disable jboss impl completely by commenting the contents of module.xml under JBOSS_HOME\modules\system\layers\base\javax\ws\rs\api\main to stop loading the Jboss JAX-RS API and it worked fine
This error is caused by the jar file conflict.I deleted jetty.jar,jetty-util.jar and also deleted jsr305.jar,the REST API just work fine.
On WAS8.5 liberty profile, even after I removed the wink dependency causing the error, the error would not go away. It finally turned out that I needed to stop & start my server. The solution was posted at the very bottom of this link https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014940544
After deploying my rails 3 app in production I noticed that paths are not always shown in the browser window. For example going to login or my_profile links would still only show http://my_app.com instead of expected http://my_app.com/login or http://my_app.com/my_profile. The views did change and were functional. I could also see the database being hit and views being rendered from the logs (which led me to believe it was not a simple browser cache issue). Going directly to http://my_app.com/login worked, however, using the links in the app would take me to the expected place while leaving the login url displayed. I tried it in several browsers (firefox, opera and chrome) and got the same behavior. The app was deployed under nginx + passenger and later nginx + thin cluster. My question is, whats going on? Could it be nginx settings or my production environment settings? I am not sure where to start.
Running curl -v my_app.com shows
* About to connect() to my_app.com port 80 (#0)
* Trying xx.xx.xx.xx... connected
* Connected to my_app.com (xx.xx.xx.xx) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.21.1 (x86_64-apple-darwin10.4.0) libcurl/7.21.1 OpenSSL/1.0.0a zlib/1.2.5 libidn/1.19
> Host: my_app.com
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Set-Cookie: ARPT=PKKIKIS10.0.81.64CKILJ; path=/
< Content-Type: text/html; charset=utf-8
< Status: 200
< X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 2.2.5
< ETag: "fce6dec3543058bec16175466020a906"
< X-Runtime: 7
< Content-Length: 787
< Cache-Control: private, max-age=0, must-revalidate
< Server: nginx/0.7.62 + Phusion Passenger 2.2.4 (mod_rails/mod_rack)
< P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
< X-Cache: MISS from server.com
< Via: 1.0 server.com:8080
< Connection: close
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
<html>
<head>
<title>http://my_app.com/</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
<meta name="generator" content="Hover Redirect Service">
</head>
<frameset framespacing="0" rows="100%,*" cols="100%" frameborder="no" border="0">
<frame name="DDIRECTXYZZY2" scrolling="auto" src="http://xxx.xx.xxx.xxx" noresize>
<frame name="DDIRECTXYZZY" scrolling="no" noresize>
<noframes>
<h1>http://my_app.com/</h1>
<p>Please click here to view the non-framed versi
on.</p>
</noframes>
</frameset>
</html>
So that is clearly a problem. The whole thing gets framed by the DNS redirect? The setup is not Phusion Passenger + nginx. It was originally, but now its thin + nginx. Also, when going directly to ip address of the app, things are just fine. When going to the domain name, I get the framed version. curl -v response of just the ip address also looks normal (like its loading the entire page).
The problem is almost certainly your frames. The inner frame is loading the correct content but because you're (presumably) not targeting 'top' in your links (or whatever it is), the browser is still showing the URL of the outermost frame.
Targeting frames: http://www.w3.org/TR/html4/present/frames.html#h-16.3
If you were not expecting to see frames in your response at all then it's likely they're the responsibility of a shoddy "DNS" service. Get a real DNS address pointed to your server and you'll be singing.
Did you try using another client computer to do your tests? If I follow your explication, that's one option you haven't investigated.
Can you send us your nginx configuration maybe?