I'm trying to run a GWT project into DevMode, After running google compilation and lanching the devMode i'm getting a url, so when running into mozila, i'm getting the 503 error.
my console is displaying the following :
[ERROR] 503 - GET /travelApp?gwt.codesvr=127.0.0.1:49822 (127.0.0.1) 1296 bytes
Request headers
Host: localhost:8888
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Response headers
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 1296
i don't understand the problem, can you help me with that ?
What you see is the response from the webserver. The Error-Code is 503 - Service Unavailable (https://en.wikipedia.org/wiki/List_of_HTTP_status_codes).
Most likey, your application failed to start.
Do you have any logs? There might be any usefull stacktraces.
Do you use the build-in Jetty? I found out, that it's sometimes hard to get log entries from it. Maybe you can try to deploy the application to tomcat to get a more helpful errorlog.
Related
I'm trying to enable http response compression on Spring boot web application.
It works for some user-agents, and for some reason doesn't for others (specific cases below).
My basic question is:
Why http response compression (gzip) in Spring Boot works only for some User-Agent headers and where it is configured.
Spring boot reference doesn't say anything about it.
I prepared simple web application with enabled compression: sample spring-boot-compression app
There are integration tests that verify that gzip encoding works for some cases only.
I configured spring boot with:
server:
tomcat:
compression: on
compressable-mime-types: text/html,text/css,application/javascript,application/json,application/font-sfnt,application/font-woff,application/font-woff2
When I try to do some requests with curl:
$ curl -i -H "Accept-Encoding: gzip,deflate" http://localhost:8080
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Content-Encoding: gzip
Vary: Accept-Encoding
I see that Content-Encoding: gzip header is set.
When I setUser-Agent to AppleWebKit (or some other browsers like IE) it does not compress:
$ curl -i -H "Accept-Encoding: gzip,deflate" -H "User-Agent: AppleWebKit" http://localhost:8080
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Vary: Accept-Encoding
I repeated my tests with some other browsers and User-Agent header modification and received some strange results.
Here some of working (response is compressed) User-Agent headers:
- Mozilla/5.0
- Mozilla/5.0 (Windows NT 6.1; WOW64) Chrome/46.0.2490.80 Safari/537.36
- Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Firefox/34.0
- SomeUnknownBrowser
Some of not working User-Agent headers:
- AppleWebKit
- Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
- Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
- Gecko/20100101
I also tried to use compression with GzipFilter and it behaves exactly the same. Also tried embedded Jetty instead of Tomcat - same result.
Maybe I'm just missing something.
You're probably using some sort of antivirus (maybe ESET). Try turning off HTTP protection.
With Eset you can try something like: Advanced -> Internet and email -> Web Access Protection - turn off.
This worked for me with Spring 1.4
server.compression.enabled: true
server.compression.mime-types: application/json,application/xml,text/html,text/xml,text/plain,text/css,application/javascript
I'm using the Google App Engine Java SDK 1.7.2 to serve some static files. When combining multiple <include... elements under <static-files> in appengine-web.xml, I am unsure which rules will take precedence.
For example, I have the following:
<static-files>
<include path="/**.swf" expiration="365d"></include>
<include path="/**.jpg" expiration="365d"></include>
<include path="/**"></include>
<exclude path="/**.php"></exclude>
</static-files>
I believe this specifies that everything should be included in static storage, except .php files, and that .swf and .jpg files should have "cache-control" and "expires" http headers set 365 days in the future.
However, when using the Live HTTP Headers tool for Firefox, I could not see the expected headers for static files with the long expiration:
http://localhost:8888/swf/Logo.20120927.swf
GET /swf/Logo.20120927.swf HTTP/1.1
Host: localhost:8888
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20100101 Firefox/15.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Referer: http://localhost:8888/
If-Modified-Since: Thu, 27 Sep 2012 15:49:03 GMT
Cache-Control: max-age=0
HTTP/1.1 304 Not Modified
Server: Jetty(6.1.x)
----------------------------------------------------------
http://localhost:8888/images/logo-and-buttons.20120927.jpg
GET /images/logo-and-buttons.20120927.jpg HTTP/1.1
Host: localhost:8888
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20100101 Firefox/15.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Referer: http://localhost:8888/
If-Modified-Since: Thu, 27 Sep 2012 15:49:03 GMT
Cache-Control: max-age=0
HTTP/1.1 304 Not Modified
Server: Jetty(6.1.x)
My question is, if this is not operating as expected, then how do I configure my <static-files> element to achieve the desired effect?
Cheers,
Jeff.
I have answered my own question: The reason I was getting "cache-control: max-age" values of 0, and no "expires" values in my HTTP headers, was because I was just reloading the page in Firefox. Upon starting a new Private Browsing session (resetting the cache in the process), and loading the page for the first time, I received the expected headers.
I'm using Google App Engine (Java) with Google Accounts for authentication.
I've created a servlet (processSignIn.jsp) that makes sure the account should be allowed in for reasons other than a valid Google account (invite approved, etc.). If the code evaluates correctly, it issues a "response.sendRedirect(url)" to send the user to the URL specified by the "url" parameter.
If a user clicks this type of link:
<a href="<%= userService.createLoginURL("../processSignIn.jsp?url=" +
request.getRequestURI()) %>">Sign in with a Google Account</a>
Then signs in with their Google account, everything works ok with Firefox or Chrome but not with IE 9. See the requests and responses below.
Note the difference between the two GET headers... FF does not contain the "../" but IE does. I would like to continue using relative paths so I don't have to do anything odd for local dev testing.
What could be the issue?
Firefox Request:
GET http://www.[mydomain].com/processSignIn.jsp?url=/main.jsp HTTP/1.1
Host: www.[mydomain].com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
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
Connection: keep-alive
Cookie: [my cookie data]
Firefox Response:
HTTP/1.1 302 Found
Content-Type: text/html
Location: http://www.[mydomain].com/main.jsp
X-AppEngine-Estimated-CPM-US-Dollars: $0.000138
X-AppEngine-Resource-Usage: ms=18 cpu_ms=0 api_cpu_ms=0
Date: Sun, 11 Dec 2011 02:58:06 GMT
Server: Google Frontend
Content-Length: 0
IE 9 Request:
GET http://www.[mydomain].com/../processSignIn.jsp?url=/main.jsp HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Pragma: no-cache
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Cookie: [my cookie data]
Accept-Encoding: gzip, deflate
Host: www.[mydomain].com
Connection: Keep-Alive
Cache-Control: no-cache
IE 9 Response:
HTTP/1.1 400 Bad Request
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html; charset=iso-8859-1
X-AppEngine-Estimated-CPM-US-Dollars: $0.001025
X-AppEngine-Resource-Usage: ms=13 cpu_ms=32 api_cpu_ms=0
Vary: Accept-Encoding
Date: Sun, 11 Dec 2011 03:00:23 GMT
Server: Google Frontend
Content-Length: 1292
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>Error 400 BAD_REQUEST</title>
</head>
<body>
<h2>HTTP ERROR: 400</h2>
<p>Problem accessing /../processSignIn.jsp. Reason:
<pre> BAD_REQUEST</pre></p>
<hr /><i><small>Powered by Jetty://</small></i>
That can only mean that the generated <a> element has an URL with /../ inside which made MSIE and Jetty to choke. Please note that your JSP/servlet code wasn't even hit. It was Jetty who blocked the request immediately due to bad URI.
To solve the bad URI, just don't use context-relative URLs with ../, but rather use domain-relative URLs. In your case that would be
<a href="<%= userService.createLoginURL(request.getContextPath()
+ "/processSignIn.jsp?url=" + request.getRequestURI()) %>">
By the way, I wonder what that userService.createLoginURL() is supposed to do. It seems to do nothing special at all.
I am getting the below error. Env is Apache and WEblogic.
Write to the client failed: calling URL::close at line 847 of ap_proxy.cpp
Exception type [WRITE_ERROR_TO_CLIENT] raised at line 848 of ap_proxy.cpp
request [/mywebservice?WSDL] did NOT process successfully
AFroz: I am getting the same error but in Weblogic10.3 and IIS plugin. Below are my finding and resolutions
Post my application was sending to IIS server
POST <hostname/pagedetails> HTTP/1.0'
Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, /
Referer:
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729;.NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; .NET4.0C)
Content-Type: application/x-www-form-urlencoded
Host:
<b>Content-Length: 38579</b>
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cookie: `SMSESSION=
`JSESSIONID=0JppPKFpLXk8HMynBLDbBJPltLL70GvQ8Cyl56hhnXbjT7JbrgmR!847042037
Error recived
HTTP/1.1 500 Internal Server Error
Server: Microsoft-IIS/5.0
Date: Mon, 09 Jan 2012 10:56:31 GMT
Set-Cookie: SMSESSION=85psVrPSuTRavlFjc8+YLNNKjH82me4KdX8t57d3RMn/6DDYk37CarBHHbT1Z0cCJTPSH48jAhgvrlLcFgNzwwLYoTkQRaKTZljCz4wCyiuj5gsx8yPBZL4h/HkaCVZMNQam5+En3UO2G8sQJ33DviYiMiX5i/azf8m06s2MyTCk6ngT/5u5rMm2SpWBlDfW/JLUEkcRD4RjQCeMP4P0Vzt8mw3oD0O/owscfaUx/nfWCAzDFEiIPkPqkEo2pUzHbfKHoQzm3AnI9cfGMjXJ8yns7dmpOOuGI0uMQzWgsv9S1+zr2VBewY7qnAyVX1MhUP203HlHjUO9rtqnDmOIqbHLMR3PRnY60VL8qpnYcrdkpLHEQEvZLxbHFoh+BL3xVqaRZnz13Cs11BsgXWztnpMYfpl3W2qLBGJ8Cd1zuN/zzJxPY0NYdz0iSd5gOtvk+KcQvxNb1a/1VXIj60H5bsjVJIK9k2lqTN3B3qEdDZ4YpG/fKgFL4a2eLtTcUYatQhZxDGQvjWY+Yla+qu7tt0JihzIOGkqgJINPEBQLfC52ADD1tvzIW4LuFwVaPp4lojGj5ykfX1v63Xo5WbhBGoH3wo2vQlUy1eKDec3SVqygk5d1y7V178oDJfbxwMRNJnPbaVRyIVUmCcEiV3IE+MrJ+Nwy+NUD4k6CGVQ+3us0G7E5AU4tiTBPPPJuKduJfH4IkiLUx6GL+ug5JIrTQVlrQQtV4Y7bdgJ2UavRbuEnUPqTr5zNJKDElr1oXtp9emah2e7goL55Gjb/p5mFi0UvmtMOmN0ffgjyYWRVqq8p5hJ0HWi6jxQinfCrQvBPAltWPeWWT9vX/apTBVdBrbMcOIFwbBcdVeTYe6Ubb+T+uxXbEthleU25bAppP60pz5wsCh/jLLf/gXk72hg55yzDG8arfZavwOLUtFEes666tvf+L65IX6lYvjNcKei4bXz7PRHzg0tvQBGM9ymFdZA0nJ3X0IzeLzukuWLd6Wo=; path=/; domain=
Content-Type: text/html
ISAPI plug-in Error MessageMessage from the ISAPI plugin:
Internal Server failure, ISAPI plugin. Cannot continue.
Build date/time: Jan 31 2003
Change Number: 235118
When I have removed the below line from the post it gave us the correct response.
Content-Length: 38579
The server was able to process
Issue:
The error is due to the browser not sending the correct character count to the IIS server.
Actual Size of the request header is 38597
Resolution:
As in Javascript we can't remove the Content-Length from the header
We need to do the changes in IIS side
ie
In InetMgr you need to Server Node -> Application Request Routing Cache -> Server Proxy Settings and increase Buffer Setting.
Other Uri :
http://www.iis.net/download/ApplicationRequestRouting
http://forums.iis.net/t/1174461.aspx
Tools used to find the post :
tcp_reflector
www.vulcanware.com/java_tcp_reflector/index.html
Recently I notice that all action for submitting forms need to be executed twice to actually submit the values. Before this worked fine when I hard coded the resulting action path from my backing beans, but since I started to resolve all action path via the faces-config strange things has started to happen. One thing is that I need to press a submit button twice to fire the action, the browser fires the POST. I can see in firebug that two POST is fired and only the last one is processed by Glassfish.
Don know if this is side effect of the problem I experience. But many times when I do a forward the page losses CSS classes and things start to look ugly and some components (Richfaces - datatable) start to render badly. Actually I have to do redirect most of the time for things to render properly.
What can be the reason that I need to do two POST/submit before the Glassfish server will process the request ?
Why do I constantly need to redirect to make components (Richfaces) to render correctly ?
I use:
Glassfish 3.1
NetBeans 7.0.1
Richfaces 4.0-final
Sample of my Faces-config;
<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>CreateActivity</from-outcome>
<to-view-id>/app_user/activity/Create.xhtml</to-view-id>
<redirect />
</navigation-case>
</navigation-rule>
<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>CreateActivityDetail</from-outcome>
<to-view-id>/app_user/activity/UpdateDetail.xhtml</to-view-id>
</navigation-case>
</navigation-rule>
Firebug log --
First POST (doesn't work when submitted)
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
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
Connection: keep-alive
Faces-Request: partial/ajax
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://localhost:8080/humis/faces/app_user/activity/List.xhtml
Content-Length: 430
Cookie: JSESSIONID=cd70a069ad528b3923bd52f12b1c
JSESSIONID=cbe0c977cf1c550f2a57cb4b334f;
treeForm_tree-hi=treeForm:tree:resources:jmsResources:jmsDestinationResources
Pragma: no-cache
Cache-Control: no-cache
First Response
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.1 Java/Sun Microsystems Inc./1.6), JSF/2.0
Server: GlassFish Server Open Source Edition 3.1.1
Cache-Control: no-cache
Content-Type: text/xml;charset=ISO-8859-1
Content-Length: 667
Date: Thu, 18 Aug 2011 13:30:22 GMT
Second POST (the one that works)
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
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
Connection: keep-alive
Faces-Request: partial/ajax
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://localhost:8080/humis/faces/app_user/activity/List.xhtml
Content-Length: 494
Cookie: JSESSIONID=cd70a069ad528b3923bd52f12b1c;
JSESSIONID=cbe0c977cf1c550f2a57cb4b334f;
treeForm_tree-hi=treeForm:tree:resources:jmsResources:jmsDestinationResources
Pragma: no-cache
Cache-Control: no-cache
Second Response
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.1 Java/Sun Microsystems Inc./1.6), JSF/2.0
Server: GlassFish Server Open Source Edition 3.1.1
Cache-Control: no-cache
Content-Type: text/xml;charset=UTF-8
Content-Length: 145
Date: Thu, 18 Aug 2011 13:30:44 GMT
It sounds like that you've mapped the FacesServlet on multiple URL-patterns and that in some way all the autogenerated URLs to CSS and JS resources become invalid. Doing some basic debugging and investigation of the <link> and <script> URLs in the JSF-generated HTML source and the HTTP traffic with for example Firebug should give a lot of insights as to what exactly broke. You should have seen 404's for those CSS/JS resources.
As this trivial debugging information is missing in your question, I can't answer anything else than suggesting to trying to explicitly map the FacesServlet on a single URL pattern, e.g. *.xhtml.