Restlent returns nothing to a partial request - java

I building a REST-API with restlet to serve a mp3 file. But the File is created and served at the same time. More informations about that here.
It work perfectly but I only tested it in a desktop environment. When I fired up my iPad to test the API, it starts playing the File but after some seconds it stops, send a new Request and starts playing the File from the beginning.
After some researcher I find out that the iPad sends a Partial Request and therefore expects a partial response.
So I modified the Response-Header to fulfill the requirements.
I use curl to test the API :
curl -v -r 0-1 http://localhost:12345/api/path/file.mp3
Request-Header
GET /api/path/file.mp3 HTTP/1.1
Range: bytes=0-1
User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: localhost:12345
Accept: */*
Response-Header
HTTP/1.1 206 Partial Content
Date: Tue, 29 Oct 2013 12:18:11 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.1.0
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Length: 2
Content-Range: bytes 0-1/19601021
Content-Type: audio/mpeg; charset=UTF-8
Expires: Tue, 29 Oct 2013 12:18:07 GMT
Last-Modified: Tue, 29 Oct 2013 12:18:07 GMT
Error-Message
But there is no Data that comes back from the server. Curl keeps the connection open to the server and the iPad sends a new Request.
When I shut the server down curl gives me:
transfer closed with 1 bytes remaining to read
Closing connection #0
curl: (18) transfer closed with 1 bytes remaining to read
Code
And here is the code I use to return the data. As you can see, this method is just for testing and should always return 2 bytes.
private InputRepresentation rangeGetRequest() throws IOException {
final byte[] bytes = new byte[2];
bytes[0] = 68;
bytes[1] = 68;
final InputRepresentation inputRepresentation = new InputRepresentation(new ByteArrayInputStream(bytes), MediaType.AUDIO_MPEG);
return inputRepresentation;
}
I have no idea what to do. I try to write my own InputStream that returns the 2 bytes, but without success.
Or is the InputRepresentation not suitable for this area of application?
Thanks in advance

Ok, I solved the problem, it was a stupid mistake.
To modify the response-header, I used
getResponse().setEntity(new StringRepresentation(" "));
getResponse().getEntity().setSize(19601021);
getResponse().getEntity().setRange(new Range(0, 2));
getResponse().getEntity().setModificationDate(new Date());
getResponse().getEntity().setExpirationDate(new Date());
getResponse().getEntity().setMediaType(MediaType.AUDIO_MPEG);
The first line was a relic from an old test. If I just use the actual InputRepresentation that holds the two bytes and it work just fine.
What do I learn from that, first tidy up your code, then ask questions ^^

Related

Google Drive API responds with 416 HTTP code

For some reason the previously working code stopped working and server started to respond with 416.
Here are the logs of HTTP client during failing interaction:
-------------- REQUEST --------------
GET https://www.googleapis.com/drive/v3/files/0B02Nopv3SQOvOVNKaDIwTEZ3MHd?alt=media
Accept-Encoding: gzip
Authorization: <Not Logged>
Range: bytes=0-33554431
User-Agent: My app Google-API-Java-Client Google-HTTP-Java-Client/1.22.0 (gzip)
-------------- RESPONSE --------------
HTTP/1.1 416 Requested range not satisfiable
Alt-Svc: quic=":443"; ma=2592000; v="39,38,37,35"
Server: UploadServer
Cache-Control: private, max-age=0
Content-Range: bytes */0
X-GUploader-UploadID: AEnB2UqBx9B09Lnr8tG761gdoz3DkhHSNO_OzHh1LkU6B2908v17rnBGQZSNW4ZVTjbRdFtvPWWIqZGdtSrTo6ZWN7YW9nxf6d
Vary: X-Origin
Vary: Origin
Expires: Mon, 11 Sep 2017 15:23:20 GMT
Content-Length: 225
Date: Mon, 11 Sep 2017 15:23:20 GMT
Content-Type: application/json; charset=UTF-8
I was trying to download a file which is around 200000 bytes, so I thought meaning of "chuck size" changed somewhere, so it could not give 33554431 bytes of a 282177 byte file. Tried changing that to a smaller value, but no success.
Drive.Files.Get get = drive.files().get(file.getId())
MediaHttpDownloader downloader = get.getMediaHttpDownloader()
downloader.directDownloadEnabled = false
localFile.newOutputStream()
get.executeMediaAndDownloadTo(stream)
Direct download does not work either, it just downloads "0" bytes.
Does anyone know how to overcome this issue?
416 Range Not
Satisfiable
error means the server is not able to serve the requested ranges. The
most likely reason is that the document doesn't contain such ranges,
or that the Range header value, though syntactically correct, doesn't
make sense.
One of the resolutions that may provide from this forum is to:
Add "Accept-Ranges: none" to our response headers.
It appeared to be a web interface when using Firefox. It uploaded "empty" files in certain cases.
https://productforums.google.com/forum/#!topic/drive/S03wEknc75g;context-place=forum/drive

Json doesn't work with specified URL

I am a new programmer i am trying to build an app with Json.
If i use this URL doesn't work . http://zsuzsafodraszat.hostzi.com/boltok.json
if i Use this, my app working. https://api.myjson.com/bins/3zm8i
Both Json files exactly the same.
Can you help me what i am doing wrong ? Maybe bad extension or web000 is not a good service for Json ? Can you give me some good free json hosting ? Thanks
Those 2 urls do not have the same content or the same headers. You can see this if run curl commands from the command line:
$ curl -i "http://zsuzsafodraszat.hostzi.com/boltok.json"
HTTP/1.1 200 OK
Date: Wed, 13 Apr 2016 22:52:50 GMT
Server: Apache
Last-Modified: Wed, 13 Apr 2016 16:48:23 GMT
Accept-Ranges: bytes
Content-Length: 1020
Connection: close
Content-Type: application/json
??{"Aldi":"http://catalog.aldi.com/emag/hu_HU/print/Online_katalogus_04_07/Online_katalogus_04_07.pdf",
"Lidl":"http://www.lidl.hu/statics/lidl-hu/ds_doc/HU_HHZ_kw14_2016.pdf",
"Spar":"http://ajanlatok.spar.hu/view/download/?d=1279",
"Penny":"https://view.publitas.com/16538/136265/pdfs/016f82fb5b00bc97b5a8c35f512d89b01cd3e3ce.pdf",
"Coop":"https://view.publitas.com/2556/133497/pdfs/16603d7e9bf30e8a8a4efec7f01d3fa2caf92fe0.pdf",
"Auchan":"http://www.lidl.hu/statics/lidl-hu/ds_doc/HU_HHZ_kw14_2016.pdf"}
$ curl -i "https://api.myjson.com/bins/3zm8i"
HTTP/1.1 200 OK
Server: nginx/1.5.8
Date: Wed, 13 Apr 2016 22:52:56 GMT
Content-Type: application/json
Content-Length: 500
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
{"Aldi":"http://catalog.aldi.com/emag/hu_HU/print/Online_katalogus_04_07/Online_katalogus_04_07.pdf","Lidl":"http://www.lidl.hu/statics/lidl-hu/ds_doc/HU_HHZ_kw14_2016.pdf","Spar":"http://ajanlatok.spar.hu/view/download/?id=1279","Penny":"https://view.publitas.com/16538/136265/pdfs/016f82fb5b00bc97b5a8c35f512d89b01cd3e3ce.pdf","Coop":"https://view.publitas.com/2556/133497/pdfs/16603d7e9bf30e8a8a4efec7f01d3fa2caf92fe0.pdf","Auchan":"http://www.lidl.hu/statics/lidl-hu/ds_doc/HU_HHZ_kw14_2016.pdf"}
As you can see, one of them has a couple of junk bytes at the beginning that my terminal is displaying as question marks. Also the http headers are different. The Content-Lengths are wildly different too. Did you use something other than a plain text editor to create the json payload in the failing example?
Try removing the junk characters and adding these http headers:
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

buffering issue with java communicating vlc

I'm a newbie to Socket communication, so I may be wrong, but please advice or at least give the direction!
I'm implementing an RTSP server according to http://www.csee.umbc.edu/~pmundur/courses/CMSC691C/lab5-kurose-ross.html#appendix taking a look to the similar code from http://www.java2s.com/Open-Source/Android/UnTagged/mynpr/com/webeclubbin/mynpr/RTSPserver.java.htm
At the moment I'm implementing responce to the OPTIONS request. To make it easy in the first approach, I decided to hardcode the answer according to the sample RTSP request/response log done for some real communication between vlc and gstreamer rtsp.
So, the log recorded with vlc URL -vvv says:
Sending request: OPTIONS rtsp://localhost:8554/test RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2013.04.30)
Received 183 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 2
Public: OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN
Server: GStreamer RTSP server
Date: Tue, 10 Sep 2013 19:56:53 GMT
Sending request: DESCRIBE rtsp://localhost:8554/test RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2013.04.30)
Accept: application/sdp
i.e.
RTSP/1.0 200 OK
CSeq: 2
Public: OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN
Server: GStreamer RTSP server
Date: Tue, 10 Sep 2013 19:56:53 GMT
part is 183 bytes length
I'm writing to the buffer right according to the example:
try{
System.out.println("S -> C");
System.out.println("RTSP/1.0 200 OK");
System.out.println("CSeq: "+RTSPSeqNb);
//System.out.println("Session: "+RTSP_ID);
if (responceType==OPTIONS) {System.out.println("Public: OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN");};
if (responceType==OPTIONS) {System.out.println("Server: GStreamer RTSP server"); };
if (responceType==OPTIONS) {System.out.println("Date: Tue, 10 Sep 2013 19:56:53 GMT");};
RTSPBufferedWriter.write("RTSP/1.0 200 OK"+CRLF);
RTSPBufferedWriter.write("CSeq: "+RTSPSeqNb+CRLF);
//RTSPBufferedWriter.write("Session: "+RTSP_ID+CRLF);
if (responceType==OPTIONS) {RTSPBufferedWriter.write("Public: OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN"+CRLF);};
if (responceType==OPTIONS) {RTSPBufferedWriter.write("Server: GStreamer RTSP server"+CRLF); };
if (responceType==OPTIONS) {RTSPBufferedWriter.write("Date: Tue, 10 Sep 2013 19:56:53 GMT"+CRLF); };
RTSPBufferedWriter.write("Session: "+RTSP_ID+"\r"+CRLF);
RTSPBufferedWriter.flush();
//RTSPBufferedWriter.newLine();
System.out.println("RTSP Server - Sent response to Client.");
}
catch(IOException ex)
{
System.out.println("Exception caught: "+ex.getStackTrace());
// System.exit(0);
}
and the vlc log says
Opening connection to 127.0.0.1, port 6666...
...remote connection opened
Sending request: OPTIONS rtsp://127.0.0.1:6666/autostream.mjpg RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2013.04.30)
Received 193 new bytes of response data.
[0x7fd01c001178] live555 demux debug: connection timeout
[0x7fd01c001178] live555 demux error: Failed to connect with rtsp://127.0.0.1:6666/autostream.mjpg
Where CRLF is '\n'. Before I tried CRLF="\r\n" (and no +"\r"+ in the last line) with
Received 198 new bytes of response data.
So, what is wrong there? What vlc is waiting for? Why default delimeters from the example doesn't work for it?
I looks like I always find the answer to my questions after I publish them to stackoverflow...
DOUBLE CRLF should stand after the last header for the usual RTSP protocol 9not the customized one used in the example).

Copying an image from url using java

I am trying to download an image from URL. I use the Apache Commons library:
org.apache.commons.io.FileUtils
.copyURLToFile(
new URL(
"https://lh3.ggpht.com/AXYMUV5cpne2vE9U3X8x87HgrbwijwiG50_yOnehU2MUPKDoJky-BKFOPZzZ07Pug8U=h230"),
new File("test.png"));
While opening the image it says not an PNG file. Is this a good way to download images from url to local?
Updated .
Thankyou guys for your answers i undestand that i need to get the connection.getContentType(); and then save it as jpg or png as it is.
if you check the url, It is JPEG file. Try to execute program after renaming file name to test.jpeg..
Checking for the content type see this SO Question.
Then use this to save the file to the right type.
Running wget on this URL and looking at the HTTP response, looks like the file type is explicitly specified as JPEG:
--2012-06-27 16:55:30-- https://lh3.ggpht.com/AXYMUV5cpne2vE9U3X8x87HgrbwijwiG50_yOnehU2MUPKDoJky-BKFOPZzZ07Pug8U=h230
Resolving lh3.ggpht.com... 74.125.237.108, 74.125.237.106, 74.125.237.107, ...
Connecting to lh3.ggpht.com|74.125.237.108|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.0 200 OK
Access-Control-Allow-Origin: *
ETag: "v1"
Expires: Thu, 28 Jun 2012 06:50:40 GMT
Content-Disposition: inline;filename="unnamed.jpg"
Content-Type: image/jpeg
X-Content-Type-Options: nosniff
Date: Wed, 27 Jun 2012 06:50:40 GMT
Server: fife
Content-Length: 46597
X-XSS-Protection: 1; mode=block
Cache-Control: public, max-age=86400, no-transform
Age: 290
Connection: Keep-Alive
Length: 46597 (46K) [image/jpeg]

What does it mean when a DataInputStream keeps returning 0?

I have a DataInputStream, created from a Socket in Java. The connection is to a simple web server that uses chunked transfer encoding. The web server does in fact work in normal browser. But in my program, I am attempting to read, I read the first first bytes (some 5kb of data). But each read after that returns 0 bytes read. Isn't it supposed to block until it can read?
Note: This usually doesn't occur. The problem is with the server I am connecting to.
Also, this code here all returns false even after the bytesread == 0.:
System.out.println(socket.isClosed());
System.out.println(socket.isInputShutdown());
System.out.println(socket.isOutputShutdown());
And here are the resp headers:
HTTP/1.1 200 OK
Date: Tue, 08 Jun 2010 14:01:01 GMT
Server: Apache/2.2.11 (Unix) PHP/5.2.10
X-Powered-By: PHP/5.2.10
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
According to http://java.sun.com/j2se/1.4.2/docs/api/java/io/DataInputStream.html#read(byte[]) it is possible and valid for a DataInputStream to return 0. This should not be a problem since you should be testing for -1 for the end of stream.
You are right, an InputStream should never return 0 on a read. It should either block until a byte is available, or return -1 which indicates EOF.
Any chance you could provide a test case? I've seen a bug like this before.

Categories