Using Eclipse's internal representation of Tomcat8 (do not know if that is relevant), the following is a series of page requests. This comes from the file:
C:\Users\BS\Eclipse\workspace.metadata.plugins\org.eclipse.wst.server.core\tmp0\logs\localhost_access_log.2016-04-25.txt:
"GET /ProjK/ HTTP/1.1" 200 16354
"GET /ProjK/WEFiles/Css/v02/openElement.css?v=50491098000 HTTP/1.1" 200 16354
"GET /ProjK/Templates/BaseLayer.css?v=50491098000 HTTP/1.1" 200 16354
"GET /ProjK/index.css?v=50491098000 HTTP/1.1" 200 16354
"GET /ProjK/WEFiles/Client/jQuery/migrate.js?v=50491098000 HTTP/1.1" 200 16354
"GET /ProjK/WEFiles/Client/Common/oe.min.js?v=50491098000 HTTP/1.1" 200 16354
"GET /ProjK/Files/Image/Template/Top.png HTTP/1.1" 200 16354
"GET /ProjK/Files/Image/Template/Logo.png HTTP/1.1" 200 16354
"GET /ProjK/Files/Image/BioTransparent.png HTTP/1.1" 200 16354
"GET /ProjK/WEFiles/Image/WEImage/PuceImg-3f204a74.png HTTP/1.1" 200 16354
"GET /ProjK/WEFiles/Image/empty.png HTTP/1.1" 200 16354
Observe that each response is the same byte count. The browser receives the content of the same file regardless of the request.
The content is from "index.html" that has been renamed to "index.ftl" and renamed back to "index.html". I have been making simple edits to this file hoping to see any change in what the browser shows.
I see that the file "index.html" has been updated with the new content in both the workspace and the /tmp0/webapps/ folder.
Yet, there are no changes in what is delivered to the browser.
A number of conversations suggests that Tomcat caching be dealt with. I would have to wonder why, during app development, this is an actual consideration.
But caching does not explain why every page and page resource request is served the same unchanging content.
What common mistake would a new java web app developer be making with respect to the setup/configuration of Tomcat and/or Eclipse and or the webapp that would explain this behavior?
Related
I am testing REST API using rest-assured. When I send POST request it looks like rest-assured is making extra call. Here is the output from /var/log/httpd/access_log:
11.31.41.111 - - [26/Nov/2019:19:39:14 +0000] "POST /rest/v1/contact HTTP/1.1" 401 340 "-" "Apache-HttpClient/4.5.3 (Java/1.8.0_221)"
11.31.41.111 - - [26/Nov/2019:19:39:14 +0000] "POST /rest/v1/contact HTTP/1.1" 200 515 "-" "Apache-HttpClient/4.5.3 (Java/1.8.0_221)"
When I send exactly same request using Postman, access log shows only one request comes to the server:
11.31.41.111 - - [26/Nov/2019:19:40:44 +0000] "POST /rest/v1/contact/ HTTP/1.1" 200 529 "-" "PostmanRuntime/7.19.0"
Any idea why this is happening?
You should use Preemptive Authentication when building RestAssured request specification. Here's an example:
RestAssured.given().auth().preemptive().basic("username", "password")
.when().get("http://example.com")
.then().statusCode(200);
I'm using 2 agents to consume a REST webservice : Apache HttpClient and CURL.
Both the clients receive different size of data for the same REST webservice. Moreover the CURL is receiving inconsistent amount of bytes all the time while the Apache HttpClient is consistent.
Below is the access log snippet with number to bytes received.
"POST <<url>> HTTP/1.1" 200 10083053 "-" "Apache-HttpClient/4.3.1 (java 1.5)"
"POST <<url>> HTTP/1.1" 200 10083053 "-" "Apache-HttpClient/4.3.1 (java 1.5)"
"POST <<url>> HTTP/1.1" 200 10083053 "-" "Apache-HttpClient/4.3.1 (java 1.5)"
"POST <<url>> HTTP/1.1" 200 10128377 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu)
"POST <<url>> HTTP/1.1" 200 10128674 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu)
"POST <<url>> HTTP/1.1" 200 8192 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu)
What could be the problem with CURL receiving inconsistent amount of bytes?
In my project, we have a component that includes a JavaScript file & in that file, we are making an AJAX call to a Servlet (defined in an OSGi bundle).
When the package is installed in the Publish instance (along with the OSGi bundle), I'm able to see results after I click on a link which is bound to the AJAX call.
When accessing the same page through the Dispatcher however, the page is getting displayed but the link which should show content from the OSGi bundle is not working. The same link is working fine when accessed directly via the Publish instance
Updated:
The access.log in Dispatcher (Apache Web Server)
Success log of dispatcher
domain - - [11/Jul/2014:15:25:11 +0530] "GET /content/sample.html HTTP/1.1" 200 25805
Failure log on one of the links on the above page
domain - - [11/Jul/2014:15:25:12 +0530] "GET /bin/servlet/SampleServlet?action=GET_SAMPLE_USAGE HTTP/1.1" 404 230
It is not finding GET_SAMPLE_USAGE servlet, but the same is already available in the OSGi bundle and is working perfectly fine via the Publish instance (logs below).
Publisher access.log
domain - admin 11/Jul/2014:15:24:31 +0530 "GET /content/sample.html HTTP/1.1" 200 25805 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0"
domain - admin 11/Jul/2014:15:24:31 +0530 "GET /bin/servlet/SampleServlet?action=GET_SAMPLE_USAGE HTTP/1.1" 200 - [this is not a link] ( "domain:4503/content/sample.html" ) "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0"
Over the last several weeks we have seen a HUGE increase in BW usage but not in page views. I finally researched the access_logs and found a TON of lines like this in there:
173.252.103.0 - - [09/Mar/2013:17:48:19 -0500] "GET /files/imagecache/article_max_width/news/2013-03-04/H_h90_110.jpg HTTP/1.1" 403 344 "-" "facebookexternalhit/1.1 (+h
ttp://www.facebook.com/externalhit_uatext.php)"
173.252.103.2 - - [09/Mar/2013:17:48:19 -0500] "GET /files/imagecache/article_max_width/news/2013-03-04/NT_audyssey_wireless_mediaa.jpg HTTP/1.1" 403 362 "-" "facebooke
xternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"
173.252.103.3 - - [09/Mar/2013:17:48:19 -0500] "GET /files/imagecache/article_max_width/news/2013-03-05/TR_board.jpg HTTP/1.1" 403 343 "-" "facebookexternalhit/1.1 (+ht
tp://www.facebook.com/externalhit_uatext.php)"
173.252.103.6 - - [09/Mar/2013:17:48:19 -0500] "GET /files/imagecache/article_max_width/news/2013-03-03/LG%20Optimus%20G.jpg HTTP/1.1" 403 347 "-" "facebookexternalhit/
1.1 (+http://www.facebook.com/externalhit_uatext.php)"
173.252.103.4 - - [09/Mar/2013:17:48:19 -0500] "GET /files/imagecache/article_max_width/review/2013-03-04/5-lit.jpg HTTP/1.1" 403 342 "-" "facebookexternalhit/1.1 (+htt
p://www.facebook.com/externalhit_uatext.php)"
173.252.103.2 - - [09/Mar/2013:17:48:19 -0500] "GET /files/imagecache/article_max_width/review/2013-03-02/IMG_9546.JPG HTTP/1.1" 403 345 "-" "facebookexternalhit/1.1 (+
http://www.facebook.com/externalhit_uatext.php)"
173.252.103.1 - - [09/Mar/2013:17:48:19 -0500] "GET /files/imagecache/article_max_width/news/2013-03-05/deal0305.png HTTP/1.1" 403 343 "-" "facebookexternalhit/1.1 (+ht
tp://www.facebook.com/externalhit_uatext.php)"
173.252.103.4 - - [09/Mar/2013:17:48:19 -0500] "GET /files/imagecache/article_max_width/news/2013-03-05/H_Geforce.jpg HTTP/1.1" 403 344 "-" "facebookexternalhit/1.1 (+h
ttp://www.facebook.com/externalhit_uatext.php)"
There is literally PAGES of them over days and days. I can't figure out what is going on here and I really don't want to use Apache to block the "facebookexternalhit" robot.
Any ideas?
I had same problems on my server. I solved it, by removing the og:url metatag and by changing the og:image metatag as I mentioned here: https://stackoverflow.com/a/24107181/3248313
The application has a page with thumbnails. Clicking on a thumbnail calls the SetURL() javascript function on the player object.
In Safari on Windows, about 75% of the time, the plugin makes the request, sends the cookie, and life is good. The other 25% of the time, it fails to load at all half the time and when it does load, it won't loop. When it fails, we see the following requests:
127.0.0.1 - [20/May/2009:11:15:19 -0400] "GET /full/?id=1 HTTP/1.1" 302 - "-" 80 7542 0 QuickTime/7.6 (qtver=7.6;os=Windows NT 5.1Service Pack 3)
127.0.0.1 - [20/May/2009:11:15:19 -0400] "GET /denied/ HTTP/1.1" 200 3385 "-" 80 9050 0 QuickTime/7.6 (qtver=7.6;os=Windows NT 5.1Service Pack 3)
127.0.0.1 - [20/May/2009:11:15:20 -0400] "GET /full/?id=1 HTTP/1.1" 200 2639638 "-" 80 2005787 2 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
The first request comes directly from the plugin and the request does not contain the session cookie, so the app redirects it to the "unauthorized access" page. We then see the plugin make the request to the redirected page. Then we see the same initial request from the browser itself. That request contains the cookie so it succeeds. About half the time, the movie plays, the other half it doesn't.
As I said, if we have 10 thumbnails on a page, everything works fine for at least 7 of them so we know the plugin is actually loaded. There are no javascript errors.
I have seen similar behavior in IE, but have not been able to reproduce it consistantly.
Thoughts?
On our development servers we password protect the sites at the server level (via htpasswd).
In Firefox, the first time the SetURL() was called for a new movie, the browser would wait and pop the password alert, regardless of whether or not it was "remembered" in the keychain. Once the credentials were sent, then QuickTime would load the movie.
In Chrome, it was remembered.
IE still won't swap the file. Downloading Charles Proxy now...