I have RESTful API for a Spring Boot application. I ran into this when I was trying to figure out a separate issue that involved trying to add custom media-types.
After trying to do this I got a HttpMediaTypeNotAcceptable exception when I try to view my API documentation. This exception is visible only in the logs (if I turn the level up to DEBUG). On the browser I see 406 undefined. Here's a screenshot:
The exception I get from Spring Boot's logs is this:
2014-11-04 10:08:26.189 DEBUG 5496 --- [nio-8080-exec-9] .w.s.m.s.DefaultHandlerExceptionResolver : Resolving exception from handler [public org.springframework.http.ResponseEntity<com.wordnik.swagger.model.ResourceListing> com.mangofactory.swagger.controllers.DefaultSwaggerController.getResourceListing(java.lang.String)]: org.springframework.web.HttpMediaTypeNotAcceptableException: Could not find acceptable representation
The root of the problem is that the existing, producible-media-types are overwritten.
Without the code above, the list contains:
application/hal+json
application/json;charset=UTF-8
application/*+json;charset=UTF-8.
With my changes, the list only contains application/hal+json and my custom media-type. So what happens is that Spring cannot find a compatible media-type at all because Swagger UI has application/json in its Accept: header whereas http://localhost:8080/api-docs vends application/hal+json (I verified using curl):
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
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
X-Application-Context: application
Content-Type: application/hal+json
Transfer-Encoding: chunked
Date: Tue, 04 Nov 2014 16:56:57 GMT
I'm guessing that Swagger UI should probably set the accept header to application/json,application/hal+json or perhaps use a wildcard like application/*+json.
The current solution would be to update swagger-client.js - The part where the SwaggerClient is built, it is hard coded with application/json as the mime type.
The current line of code is https://github.com/swagger-api/swagger-ui/blob/master/dist/lib/swagger-client.js#L335 though that may obviously change in different versions (so may not be relevant in the future when reading this answer).
The swagger-client.js exists in two places - the /dist/lib dir for the pre-built application or directly under the /lib dir for the build process. You should change the value depending on what you're using.
Related
I've written a query tool which at it's heart uses this block to gather info from an external url:
AsyncHttpClientConfig proxiedCF = new DefaultAsyncHttpClientConfig.Builder().setUserAgent(pickUserAgent()).build();
AsyncHttpClient asyncHttpClient = new DefaultAsyncHttpClient(proxiedCF);
Future<Response> f = asyncHttpClient.prepareGet(url).setProxyServer(new ProxyServer.Builder(pickProxyServer(), 80)).execute();
It works fine. However it works even when an invalid proxy is provided, which is a bit suspicious and I feel my elaborate proxy configuration is not used at all.
I stumbled upon this by having pickProxyServer() return a String "1.1.1.1", which is obviously not a valid web proxy.
I use SLF4J for logging and it looks pretty normal:
20:31:47.454 [AsyncHttpClient-7-1] DEBUG o.a.n.channel.NettyConnectListener - Using new Channel '[id: 0x03359938, L:/10.0.0.101:59775 - R:/1.1.1.1:80]' for 'GET' to '[[url removed by me]]'
20:31:47.586 [AsyncHttpClient-7-1] DEBUG o.a.netty.handler.HttpHandler -
Request DefaultFullHttpRequest(decodeResult: success, version: HTTP/1.1, content: EmptyByteBufBE)
GET [[url removed by me]] HTTP/1.1
Host: [[url removed by me]]
Accept: */*
User-Agent: burning_dandelion
Response DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
HTTP/1.1 200 OK
Date: Fri, 13 Oct 2017 18:31:49 GMT
Expires: Fri, 13 Oct 2017 18:31:49 GMT
Cache-Control: private, max-age=3600
Content-Type: text/xml; charset=ISO-8859-1
P3P: CP="This is not a P3P policy!"
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Set-Cookie: 1P_JAR=2017-10-13-18; expires=Fri, 20-Oct-2017 18:31:49 GMT; path=/; domain=[[url removed by me]]
Set-Cookie: NID=114=qiVBv02cmXYHh2RfLQbhBfESWIoaGlf3d2jlSbAdQ8yWPDsCpOeK9aYbvfq0HWsER68W1oE53jiriM_fivTc1bJi1F2sfCi0wMptKI-9U3ueVKITtFvYYZx2T0rJf1kQ; expires=Sat, 14-Apr-2018 18:31:49 GMT; path=/; domain=[[url removed by me]]; HttpOnly
Accept-Ranges: none
Vary: Accept-Encoding
Transfer-Encoding: chunked
20:31:47.587 [AsyncHttpClient-7-1] DEBUG o.a.netty.channel.ChannelManager - Adding key: ProxyPartitionKey(proxyHost=1.1.1.1, proxyPort=80, secured=false, targetHostBaseUrl=[[url removed by me]]:80 for channel [id: 0x03359938, L:/10.0.0.101:59775 - R:/1.1.1.1:80]
Can someone point me towards my error? Obviously, I want an I/O exception or any kind of notice when an invalid proxy is called upon.
Ok it's the middle of the night but I found something. When the port is anything but :80, the proxy is correctly used. This does the trick for me.
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'm trying to use JMeter to test a restful endpoint for uploading files, but I'm getting a 400 error. The one thing that jumps out at me is the boundary value; it's not the same I provided as the one shown in the request. I'm able to use the endpoint in the browser without issue, and I've replicated the headers revealed in the developer tools in FF.
Here is the relevant info from JMeter:
Result Tab:
Thread Name: Asdf - Load Test 1-1
Sample Start: 2017-06-05 08:47:46 EDT
Load time: 159
Connect Time: 28
Latency: 159
Size in bytes: 438
Sent bytes:821003
Headers size in bytes: 438
Body size in bytes: 0
Sample Count: 1
Error Count: 1
Data type ("text"|"bin"|""):
Response code: 400
Response message: Bad Request
Response headers:
HTTP/1.1 400 Bad Request
Date: Mon, 05 Jun 2017 12:47:46 GMT
Server: Apache/2.4.25 (Win64) OpenSSL/1.0.2k
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Cache-Control: no-cache, must-revalidate
Content-Length: 0
Connection: close
HTTPSampleResult fields:
ContentType:
DataEncoding: null
Request Tab:
POST https://localhost/my/rest/endpoint
POST data:
--9amm365-gMmimP70lvs9jIvlIxOfkocUN
Content-Disposition: form-data; name="parseable"; filename="asdf.docx"
Content-Type: application/vnd.openxmlformats-
officedocument.wordprocessingml.document
Content-Transfer-Encoding: binary
--9amm365-gMmimP70lvs9jIvlIxOfkocUN--
[no cookies]
Request Headers:
Connection: keep-alive
Content-Type: multipart/form-data; boundary=--Uc_2uLvcVgc7SqvzIJxR3encUKw-
f7w9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Accept: application/json, text/plain, /
X-Request-OnBehalfOf: some-user-uuid
X-Requested-With: XMLHttpRequest
Content-Length: 820532
Host: localhost
User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_121)
Response Data Tab is blank.
Server side implementation:
#POST
#Override
#EnhancedDetail
#Consumes(MediaType.MULTIPART_FORM_DATA)
#Path("my/rest/endpoint")
public Response uploadProduct(#PathParam("id") final String id, MultiPart multipart) throws IOException {
return processMultiFileUpload(id, multipart, MultiPartUploadType.DRAFT, false);
}
If you are building your request manually like it is described in Testing REST API File Uploads in JMeter article - make sure you have Use multipart/form-data for POST box of the HTTP Request sampler is not checked.
And vice versa, if you tick this box, you won't need to override the Content-Type header
I believe the easiest way would be just recording your file upload event using HTTP(S) Test Script Recorder (just make sure your asdf.docx file is copied to the "bin" folder of your JMeter installation)
I figured it out. I changed the Client Implementation on the HTTP Request to Java. Everything I've read said use HttpClient4, but I tried Java and it worked.
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'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