I'm working on a Android sample app that get film list from http://www.omdbapi.com/.
The REST service is:
http://www.omdbapi.com/?s=star&apikey=d497e644
I'm using Retrofit to write the client.
public interface OmdbApi {
#Streaming
#GET("./")
#Headers({"Cache-control: no-cache"})
Call<Search> search(#Query("s") String search, #Query("apikey") String apiKey);
#Streaming
#GET("./")
#Headers({"Cache-control: no-cache"})
Call<FilmDetail> getFilm(#Query("i") String uid, #Query("apikey") String apiKey);
}
The complete source code is available here.
When I run the application, I obtain the following response (taken from logcat):
OK http://www.omdbapi.com/?s=star&apikey=d497e644 (108ms)
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Cache-Control: public, max-age=86400
Expires: Sat, 26 May 2018 14:28:18 GMT
Last-Modified: Fri, 25 May 2018 05:39:04 GMT
Vary: *, Accept-Encoding
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
CF-Cache-Status: HIT
Server: cloudflare
CF-RAY: 4208b00c817b3db9-MXP
Connection: Keep-Alive
And the following error:
java.net.ProtocolException: unexpected end of stream
at okhttp3.internal.http1.Http1Codec$ChunkedSource.read(Http1Codec.java:455)
at okio.RealBufferedSource.read(RealBufferedSource.java:47)
okio.RealBufferedSource.exhausted(RealBufferedSource.java:57)
okio.InflaterSource.refill(InflaterSource.java:102)
okio.InflaterSource.read(InflaterSource.java:62)
okio.GzipSource.read(GzipSource.java:80)
okhttp3.logging.HttpLoggingInterceptor.intercept(HttpLoggingInterceptor.java:237)
okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:200)
at okhttp3.RealCall.execute(RealCall.java:77)
at retrofit2.OkHttpCall.execute(OkHttpCall.java:180)
retrofit2.ExecutorCallAdapterFactory$ExecutorCallbackCall.execute(ExecutorCallAdapterFactory.java:91)
com.abubusoft.filmfinder.service.repository.FilmRepository.lambda$findFilm$0$FilmRepository(FilmRepository.java:18)
com.abubusoft.filmfinder.service.repository.FilmRepository$$Lambda$0.run(Unknown Source:20)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)
After a bit of investigation, I found that the problem is that the response has Transfer-Encoding: chunked. How can I resolve this problem?
Thank you.
After more investigation:
I remove the #Streaming annotations.. they aren't useful.
Tests that I did was on an emulator on a PC behind a firewall.
OkHttp had some problem about it many years ago, but now chunked transfer is completely managed.
On the same machine, invoking the same URL in a browser does not present any problems
I finally try on another machine, with a JUnit test and in Android emulator and I had no problem.
At last, I'm sure that code works, so is the environment that I used to develop the app has some problem with transfer-encoding chunked.
Complete source code is available here:
android app
junit test
I have to find exactly what is the problem, I'm sure now that it not Retrofit or my client definition or OkHttp.
I hope my experience can help other developers.
Byez
Related
Using certbot fails to generate certificate with this error:
org.shredzone.acme4j.exception.AcmeException: Failed to pass the challenge for domain www.
mysampledomain123.com, ... Giving up.
I manually checked the challenge file and got
http://www.mysampledomain123.com/.well-known/acme-challenge/jU--PkDrn5tDZw2RN6NNJHbPD00ovHFkLFvN3mJdeQX
Inside the file:
jU--PkDrn5tDZw2RN6NNJHbPD00ovHFkLFvN3mJdeQX.tuMr-UijwpsJ1KVZkdWTYgodWZ2SxxKdB7_CMAAEfpg
And here's the complete HTTP response header:
Accept-Ranges: bytes
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/plain;charset=iso-8859-1
Date: Sun, 16 Feb 2020 14:15:22 GMT
Server: nginx/1.14.0 (Ubuntu)
Transfer-Encoding: chunked
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
X-Powered-By: MyServer
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 999
X-RateLimit-Reset: 0
I'm wondering whether the problem is with the HTTP response headers or the content itself.
Any ideas would be appreciated.
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
I have a rest API which I am testing using Jmeter. The response message assertion for message "OK" is failing.
Following are the response headers I see
HTTP/1.1 200
Set-Cookie: JSESSIONID=BE7C763B232F61E6DCECFSDEDEDB;path=/test-service;HttpOnly
X-Application-Context: test-service:DEFAULT,dev:8098
Link:
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 15 Feb 2017 09:14:30 GMT
Sampler Result
Sample Start: 2017-02-15 14:44:26 IST
Load time: 4422
Latency: 4418
Size in bytes: 4368
Headers size in bytes: 500
Body size in bytes: 3868
Sample Count: 1
Error Count: 1
Response code: 200
Response message:
When I test it through postman I get proper result
Can someone tell why this might be happening?
Note :
My Application is a spring boot app.
update :
this is not happening only in jmeter. I tried using Advance rest client
Got only the status code
If your response assertion is configured like the one given below, it shouldn't be failing. In case, if you are looking for the entire text "HTTP/1.1 200", ensure that "Response Headers" radio button is checked along with "Contains" in the pattern matching rules with text as "HTTP/1.1 200"
This is actually not jmeter issue.
HTTP/2 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line.
https://github.com/spring-projects/spring-boot/issues/6548
This is actually a Tomcat 8.5 issue as it starts to support HTTP/2 specifications.
To quote the comment in the relevant part of the Tomcat "Clients should ignore it (RFC 7230) and it just wastes bytes."
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
I'm asking myself whether IBM Connections 5.5 is not supported by IBM SBT.
The version I use is "1.1.11.20151208-1200".
My test procedure is the following:
public static void testCreateCommunity() throws ClientServicesException {
String g = Variables.aCommunityService.createCommunity( "TEST", "TESTDESCRIPTION", "public" );
if (g.isEmpty()) {
System.out.println( "x0[Failed] Creating Community has failed." );
}
else
{
System.out.println( "Creating Community successfully done." );
}
}
This code does perfectly work in Connections 5.0 CR 3 , but does not work
in IBM Connections 5.5.
I always get:
com.ibm.sbt.services.client.ClientServicesException: Request to url https://blabla.com/communities/service/atom/communities/my returned an error response 400:Bad Request HTTP/1.1 400 Bad Request [Date: Tue, 26 Jan 2016 10:20:02 GMT, X-Frame-Options: SAMEORIGIN, Strict-Transport-Security: max-age=max-age=31536000;includeSubDomains, X-XSS-Protection: 1;mode=block, X-Permitted-Cross-Domain-Policies: master-only, X-Powered-By: Servlet/3.0, Expires: Thu, 1 Jan 1970 00:00:00 GMT, Cache-Control: no-store, no-cache, must-revalidate, X-LConn-Auth: false, X-UA-Compatible: IE=edge, Last-Modified: Tue, 26 Jan 2016 10:20:02 GMT, Set-Cookie: LtpaToken2=kx9gO87/cDI8zHT1v8iwsFCP6WAbAH7FusrA8VU7jOC78KqkTEghj1XsNPRLMDT4tmIEI+diSer+++TZw1gSiC79jveQoTerr53Ggdf/zVwOVACyzA9kcpzPsaWn2+u83SkHC4s3ZCAoDGe1eq6Mb9sF2lnrn2GDrbsSzzvCPdo+pSzx4AG+0OEOa1rPX2gVF5mCfYXeqtNxUeFMc/Eibzt0zszHX5RDXZz5pcU+D1LW98B8rnar3YJjEgp8QdLT1IvhRYIo1zQQs920c9kU0tgw+CccC97fD/SRucqsHWqh2aHhs2hlTaEzMKo21o/5lD+Qwkn3QwWYFtKZntmQGLlAlJvPBQNgR2+38E4Y8uEyFy8jaBbZE0tE6MdK9zSY9Pz6zGPZaMHSV6msS+veXncynS5mcFg7jpLdsHqbQRw0Hb9w3Pe7XChaQ+yrbwTiF+mooWrCoSOYCYkA6fEVVKUbCDF0imKFWVZXOdCaszl/Ank9DFbiBSXfNGWoiXk1pJHSnoJs8C4+jBqjhbcYebpbLLTmjtS2DytMW15r97bpDekGMqFywms539c4c9QKMmjPli6L7fgYAGVsopqlMmp8AwhhuH9tXaqc6mOtbspMAKGZTn8GmvAFIVTxqfumyYLCUQvsCOgRIhdC0WlXxx/Zq+usQcvHUXwQarFhycU=; Path=/; Domain=.blabla.com, Set-Cookie: JSESSIONID=0000H65mMCw0ijcsS5e19kYaAyB:1a9lvgg03; Path=/; HttpOnly, Vary: Accept-Encoding,User-Agent, Connection: close, Transfer-Encoding: chunked, Content-Type: text/xml;charset=UTF-8, Content-Language: de-DE]
Does anybody know whether IBM SBT generally supports Connections 5.5?
We have similar issues in Communities (and Activities) use cases. Most of the functionality works fine, but you stumbled upon an issue that we also encountered.
For now we are using the REST API's to work around this.
I know we could contribute to the open source project, but that will take some time.
So I would say it generally supports 5.5, but in this specific case ...
After running into the same issue I have found a way to add the header before the createCommunity() service call. In your case it would look like this:
Variables.aCommunityService.addDefaultHeader("Content-Type","application/atom+xml")
//Then create community
https://github.com/OpenNTF/SocialSDK/issues/1772#issuecomment-239517941
HTH