Since Java 7u21 I stumbled on some strange behavior in a JavaFX applet I made.
On the server side I have a Glassfish 3 server and a mysql database. On the client side I use Jersey to fetch data from the db by sending requests to my Glassfish server. Everything works when I start the program through the JAR file, however when I start it through my JNLP file, I notice some strange behaviour since 7u21. Let me try to show you:
I do a simple request which should give a XML response:
The method (client):
public List<Users> getUsersHierarchyTreeFilteredByUserlevel(int id, int betweenStart, int betweenEnd) throws UniformInterfaceException {
WebResource resource = webResource;
resource = resource.path(java.text.MessageFormat.format("users/{0}/hierarchy", String.valueOf(id))).queryParam("start", "" + String.valueOf(betweenStart)).queryParam("end", "" + String.valueOf(betweenEnd));
System.out.println(resource.getURI());
return resource.accept(javax.ws.rs.core.MediaType.APPLICATION_XML).get(new GenericType<List<Users>>() {});
}
The URI: System.out.println(resource.getURI());
http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy?start=5&end=5
Java console:
network: Cache entry not found [url: http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy?start=5&end=5, version: null]
network: Connecting http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy?start=5&end=5 with proxy=DIRECT
network: Connecting socket://localhost:8080 with proxy=DIRECT
network: Downloading resource: http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy?start=5&end=5
Content-Length: -1
Content-Encoding: null
network: Wrote URL http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy?start=5&end=5 to File C:\Users\Steven\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\33\d7edc21-130fad10-temp
cache: Adding MemoryCache entry: http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy
java.io.IOException: stream is closed
As you can see I receive a IOException. This seems to happen at resource.accept(...) in the getUsersHierarchyTreeFilteredByUserlevel(...) method. However, when I paste the URI in my browser, it shows the correct XML data? I have no idea why... It works when running the JAR itself or with 7u17.
Any ideas?
Thanks in advance!
Update
*Fetch with wget (64bit)*
D:\>WGET64.EXE -S --http-user=*** --http-passwd=*** "http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy?start=5&end=5"
--22:06:53-- http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy?start=5&end=5
=> `hierarchy#start=5&end=5'
Resolving localhost... 127.0.0.1
Connecting to localhost[127.0.0.1]:8080... connected.
HTTP request sent, awaiting response...
1 HTTP/1.1 200 OK
2 X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.2.2 Java/Oracle Corporation/1.7)
3 Server: GlassFish Server Open Source Edition 3.1.2.2
4 Pragma: No-cache
5 Cache-Control: no-cache
6 Expires: Thu, 01 Jan 1970 01:00:00 CET
7 Content-Type: application/xml
8 Date: Wed, 05 Jun 2013 20:06:53 GMT
9 Connection: close
[ <=> ] 9,610 --.--K/s
22:06:53 (9.16 MB/s) - `hierarchy#start=5&end=5' saved [9610]
It all had to do with the same issues regarding this question:
Authentication required window popping up after 7u21 update
and follow up question:
basic authentication fails with glassfish
Answered by dennis-the-menace which you can find here:
https://stackoverflow.com/a/18362271/1527284
Related
I need to get events\log for all activities done by admin and other office365 users such as user login, user logout, create user, delete, Update
I have successfully configured office 365 management activity API and also receiving responses for following Content Type
Audit.AzureActiveDirectory
Audit. Exchange
Audit.SharePoint
DLP.All (DLP events only for all workloads)
But for Audit.General Content Type I am receiving Empty response please help me to solve this problem?
Do the Audit.General API provides the admin and users activities log.
If not in what ways I can get these logs, please advise.
Responce for Audit.General`
--> GET https://manage.office.com/api/v1.0/a153759e-c827-46b8-8223-7ceb5c246c3f/activity/feed/subscriptions/content?contentType=Audit.General http/1.1
User-Agent: java-tutorial
client-request-id: e77e2404-666b-4898-85bb-afa1d2da0cae
return-client-request-id: true
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlZXVkljMVdEMVRrc2JiMzAxc2FzTTVrT3E1USIsImtpZCI6IlZXVkljMVdEMVRrc2JiMzAxc2FzTTVrT3E1USJ9.eyJhdWQiOiJodHRwczovL21hbmFnZS5vZmZpY2UuY29tIiwiaXNzIjoiaHR0cHM6Ly9zdHMud2luZG93cy5uZXQvYTE1Mzc1OWUtYzgyNy00NmI4LTgyMjMtN2NlYjVjMjQ2YzNmLyIsImlhdCI6MTUwMTg0MDcwMSwibmJmIjoxNTAxODQwNzAxLCJleHAiOjE1MDE4NDQ2MDEsImFjciI6IjEiLCJhaW8iOiJZMkZnWUJCeWZpRjF3Q0R6eitjMVNrR0pvaXVkWHF5L2QzaFZxTlpHeitjR1VabHp0UElCIiwiYW1yIjpbInB3ZCJdLCJhcHBpZCI6ImZhNThlYWY5LWRhNDMtNGNkYS1hYjQwLTU4MTY2MGMxYjNjMCIsImFwcGlkYWNyIjoiMSIsImZhbWlseV9uYW1lIjoiTmF2YWxlIiwiZ2l2ZW5fbmFtZSI6IkF2aW5hc2giLCJpcGFkZHIiOiI0OS4yNDguNzcuMTQiLCJuYW1lIjoiQXZpbmFzaCBOYXZhbGUiLCJvaWQiOiI2ZWMzMjRhZS0wNzhiLTRmYWEtYTQ0NC0yNmNlZDVhNDA1ZjAiLCJwbGF0ZiI6IjMiLCJwdWlkIjoiMTAwMzNGRkZBMzJDMjg4NiIsInNjcCI6IkFjdGl2aXR5RmVlZC5SZWFkIEFjdGl2aXR5RmVlZC5SZWFkRGxwIEFjdGl2aXR5UmVwb3J0cy5SZWFkIFNlcnZpY2VIZWFsdGguUmVhZCBUaHJlYXRJbnRlbGxpZ2VuY2UuUmVhZCIsInN1YiI6InY4NDdtVzl5em5wSFBIdV9La1RPdDZNblJUMUIzODZuODl0NFlLYVp5VGciLCJ0aWQiOiJhMTUzNzU5ZS1jODI3LTQ2YjgtODIyMy03Y2ViNWMyNDZjM2YiLCJ1bmlxdWVfbmFtZSI6ImF2aW5hc2huQExlb1RlY2hub3NvZnQub25taWNyb3NvZnQuY29tIiwidXBuIjoiYXZpbmFzaG5ATGVvVGVjaG5vc29mdC5vbm1pY3Jvc29mdC5jb20iLCJ2ZXIiOiIxLjAifQ.EV6j1KkH8jC6CSdnbXSPh5fT-cLxaiQiVCorOi3ljGaTJYfq6xyyTsE3nJNgq2DziHIAXKoAZkaHMu8RUZBEqhYplgvTeAdstWt-RVziJKgAFXX5jIYvZExZbnJVZDXtBr2BIgfy0rhx5sWY-XFz27VzK9bmPl2IWpLstWZ1w7N8VyBNLssGwwL_rYwjBcDqon4F-u7Xas6DyYSfkvZyMpJ3kbbAb2KK3Rmo-d2LdUfz2aF6j02u6VgmHsBNPahD8iB3KDihzWYiujAlT2OY5UrNHO1MxIGnyBod9ejmQK87FjYyJEuoRZM6b65QKUcaOTaamK-ZjJKItkEpYs-I_g
--> END GET
<-- 200 OK https://manage.office.com/api/v1.0/a153759e-c827-46b8-8223-7ceb5c246c3f/activity/feed/subscriptions/content?contentType=Audit.General (163ms)
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 2
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
X-Powered-By: ASP.NET
Date: Fri, 04 Aug 2017 10:03:25 GMT
OkHttp-Sent-Millis: 1501841286505
OkHttp-Received-Millis: 1501841286668
[]
<-- END HTTP (2-byte body)`
Currently I am working on Office 365 Management Activity API and I also faced this scenario earlier. This API was released by Microsoft merely within one year and it is in growing stage only. However, I would strongly recommend you to raise ticket to Microsoft support from your Office 365 admin portal. Microsoft support team will contact and assist you getting your problem resolved.
I'm trying to create a simple REST service to serve audio files (with seek support).
I'm using this example which is based on Jersey:
https://github.com/aruld/jersey-streaming/tree/jersey2
This is a quite simple example, it listens to GET and HEAD requests used by the browsers, look for the Range header and respond with 206 plus the archive slice requested (with byte ranges).
The catch here is that I'm re-writing this on spark java (a tiny framework with an embedded jetty server).
Every thing seems to be OK. The browser sends the GET and the server crates the response accordingly... though the player never loads nor plays anything. The request is made and the response header is perfect:
Request:
Host: localhost:4567
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: audio/webm,audio/ogg,audio/wav,audio/*;q=0.9,application/ogg;q=0.7,video/*;q=0.6,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Range: bytes=0-
Connection: keep-alive
Response:
Accept-Ranges: bytes
Content-Length: 1048577
Content-Range: bytes 0-1048576/5563904
Content-Type: audio/mp3
Date: Sat, 20 Aug 2016 05:41:23 GMT
Last-Modified: Sat Aug 20 01:12:37 BRT 2016
Server: Jetty(9.3.6.v20151106)
sasd
One thing I noticed is that seems the transfer for this request never ends. When I close the server, the transfer ends at 0,03KB (always).
My proof of concept app code:
http://pastebin.com/xjkLne7E
Found an answer!
I did some more research and found that it is a Spark feature to be implemented:
https://github.com/perwendel/spark/issues/397
User tchoulihan already tried to implement such feature with success here:
https://github.com/tchoulihan/torrenttunes-client
Here is a sample of the spark get request that handles the upload:
https://github.com/tchoulihan/torrenttunes-client/blob/master/src/main/java/com/torrenttunes/client/webservice/Platform.java#L555
I can't paste a blob here since GPLv3 would clash with cc-wiki license. Hes work is inspired on the same resource I first found. Based on that I have coded a version of my own that works on android, mozilla and chrome.
TL;DR The problem was that mozilla doesn't understand 206 request properly and I wasn't closing and flushing the ByteOutputStream. Also I tried to use the StreamingOutput from JAX as a response instead of sending a simple raw http response.
I am developing a SOAP client with Apache CXF 3.16. When I execute my client, the wildfly server respons with premature end of file. I needed to find out where this truncating has happend so I used fiddler and setup a proxy to catch the request, but then suddenly the error disappeared. Can Anyone explain what happens and I what I should do to solve this issue with CXF?
Regards
with fiddler:
ID: 1
Address: http://localhost:8080/iam/im/TEWS6/sbxd
Encoding: UTF-8
Http-Method: POST
Content-Type: text/xml
Headers: {Accept=[/], SOAPAction=["KMDCreateHRSoap"]}
ID: 1
Response-Code: 200
Encoding: UTF-8
Content-Type: text/xml;charset=utf-8
Headers: {connection=[keep-alive], Content-Length=[556], content-type=[text/xml;charset=utf-8], Date=[Tue, 07 Jun 2016 07:57:36 GMT], Server=[WildFly/8], Set-Cookie=[JSESSIONID=jnbJb_S4XZDJp-mM8XqW513q.idmapp0002; path=/iam/im], X-Powered-By=[Undertow/1]}
Without Fiddler:
ID: 1
Address: http://localhost:8080/iam/im/TEWS6/sbxd
Encoding: UTF-8
Http-Method: POST
Content-Type: text/xml
Headers: {Accept=[/], SOAPAction=["KMDCreateHRSoap"]}
Payload:
ID: 1
Response-Code: 500
Encoding: UTF-8
Content-Type: text/xml;charset=utf-8
Headers: {connection=[keep-alive], Content-Length=[983], content-type=[text/xml;charset=utf-8], Date=[Tue, 07 Jun 2016 08:03:50 GMT], Server=[WildFly/8], Set-Cookie=[JSESSIONID=OnQoW3wBypZGI8qLWrjZ9lcs.idmapp0002; path=/iam/im], X-Powered-By=[Undertow/1]}
I'm afraid this answer won't be to your taste, but your problem seems to be rooted in some security features of cxf. As a lot of attacks make use of large soap requests (extremly large element-names, content, and so on) there are certain restrictions what is allowed and what is not. You can find details for these restrictions on the cxf-site.
Perhaps you can try to set the mentioned properties as System properties during wildfly-startup.
the reason was the soap request was chunked and even though I have set allowchunk to false, but it helped with autoredirect to false and setting soap protocol to 1.2 instead instead 1.1. thx for all the help!
What is the easiest way to either configure Axis2 or extend the message listener to PREVENT any and all information regarding system from returning to the calling client?
An example of what I'm trying to prevent is as follows: Someone sends an improper soap request with some weird stuff in the header and the server responds:
HTTP/1.1 500 Internal Server Error
Date: Wed, 19 Nov 2014 13:12:34 GMT
Server: Apache
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.2.2 Java/Oracle Corporation/1.7)
Connection: close
Content-Length: 465
Content-Type: text/xml;charset=utf-8
...
<faultstring>javax.xml.stream.XMLStreamException: DOCTYPE is not allowed</faultstring>
What is the best way to prevent all of that information from being delivered back to the client? The glassfish messages can be turned off in GlassFish as answered below. I should have been more specific I want to set it up so that any and all exceptions never reach the client. I want to somehow force axis2 to use a generic message instead of returning an Exception. Is it possible to do this with Axis2?
You can add a
-Dproduct.name="".
in your JVM Option for suppressing the X-Powered-By
How do I handle properly a client Connection: close request field? As of now if I get this particular field I close the socket and wait for a following request from the client than reply again and start serving the data.
I don't know why my client/server communication is not working as the Apache Server I tested with.
Thanks for any clarifications...
Client/Server comunication:
CLIENT:
HEAD /stream.mpeg HTTP/1.0
Host: 127.0.0.1
User-Agent: SuperPlayer
Connection: Close
SERVER:
HTTP/1.0 200 OK
Date: Wed, 1 Jun 2011 20:05:13 GMT
Server: HTTP Server
Last-Modified: Mon, 06 Aug 2009 01:02:23 GMT
Accept-Ranges: bytes
Connection: Close
Content-Type: audio/mpeg
CLIENT:
HEAD /stream.mpeg HTTP/1.0
Host: 127.0.0.1
User-Agent: SuperPlayer
Connection: Close
SERVER:
HTTP/1.0 200 OK
Date: Wed, 1 Jun 2011 20:05:13 GMT
Server: HTTP Server
Last-Modified: Mon, 06 Aug 2009 01:02:23 GMT
Accept-Ranges: bytes
Connection: Close
Content-Type: audio/mpeg
231489172304981723409817234981234acvass123412323
21312hjdfaoi8w34yorhadl4hi8rali45mhalo3i,wmotw
345fqw354aoicu43yocq2i3hr
Client/ApacheServer Comunication:
CLIENT:
GET /test.mp3 HTTP/1.0
Host: 192.168.1.120
User-Agent: SuperPlayer
Connection: Close
SERVER:
HTTP/1.1 200 OK
Date: Wed, 01 Jun 2011 19:15:11 GMT
Server: Apache/2.2.16 (Win32)
Last-Modified: Thu, 29 Apr 2010 21:06:34 GMT
ETag: "14000000047049-4f75c8-4856680636a80"
Accept-Ranges: bytes
Content-Length: 5207496
Connection: close
Content-Type: audio/mpeg
...d.....<).0.. ..........<.#.. ( .h.$.J...1...i....A. ......c....a.9..!g.N...A. ........ ....>......|.......8....a......|..|N.............'>........?...C.....#..TJt.n .e...r.iL..#..IH...pR|.
Yes closing the socket is the right action to take. If the client is using this header properly, they are closing the socket on their end once they receive your response.
What I'm noticing here is that your server is not returning a Content-Length header. Even though the client is issuing a HEAD request, based on the W3C proposal (sec. 9.4):
The metainformation contained in the HTTP
headers in response to a HEAD request
SHOULD be identical to the information
sent in response to a GET request.
This method can be used for obtaining
metainformation about the entity
implied by the request without
transferring the entity-body itself.
This method is often used for testing
hypertext links for validity,
accessibility, and recent
modification.
The response to a HEAD request MAY be
cacheable in the sense that the
information contained in the response
MAY be used to update a previously
cached entity from that resource. If
the new field values indicate that the
cached entity differs from the current
entity (as would be indicated by a
change in Content-Length, Content-MD5,
ETag or Last-Modified), then the cache
MUST treat the cache entry as stale.
The key here is to make sure you're telling the client the size of the response without actually sending the data.
The Connection: close header just means that the client is expecting you to close the connection after sending the response. That also absolves you of having to send a Content-Length: header.
May I ask why are you using http 1.0 in the request?
There were no persistent connections in http 1.0, so the server is supposed to terminate the TCP connection after the response, whether you send Connection: close or not.
If you are using HTTP 1.0, there is no persistent connections as alexrs pointed, instead, Connection: keep-alive is being used with HTTP 1.0. On HTTP 1.1, you do not need that because HTTP connections are persistent by default on HTTP 1.1.
8.1.2 Overall Operation
A significant difference between HTTP/1.1 and earlier versions of HTTP
is that persistent connections are the default behavior of any HTTP
connection. That is, unless otherwise indicated, the client SHOULD
assume that the server will maintain a persistent connection, even
after error responses from the server.
Persistent connections provide a mechanism by which a client and a
server can signal the close of a TCP connection. This signaling takes
place using the Connection header field (section 14.10). Once a close
has been signaled, the client MUST NOT send any more requests on that
connection.
You can take a look at to the HTTP 1.1 RFC;
RFC for HTTP 1.1