I am using Jetty's proxy servlet to route requests from a front-end client to Couch database. In addition to proxying, I am injecting an additional details, to the incoming request that is used by the CouchDB. HTTP request is modified by extending HTTPServletRequestWrapper. When I override the getContentLength method and recalculate the size of the inputStream, only the content of size of the original request is sent to CouchDB and since the input JSON is invalid Couch DB issues a Bad Request(400 HTTP) code. In the Jetty logger, I see that contentWritten != contentLength message. Once I remove Content-Length header altogether, Jetty sends the request as expected copying all the content to the proxied request. Even if this approach works, I am wondering what really causes Jetty to not send the modified request content even when the correct content length is set by overriding the getContentLength method of ServletInputStream.
I am using Jetty 8.1.3 version and all requests are JSON requests/responses. I have also subclassed the ServletInputStream class and read() method, so I don't think there is any problem with that.
This is a chunked encoding bug fixed recently in Jetty 7.6.10-SNAPSHOT and 8.1.10-SNAPSHOT.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=401382
Fixed in Jetty-7 (and then merged into Jetty-8)
Commit #1
Commit #2
You can use Jetty 7.6.10-SNAPSHOT or 8.1.10-SNAPSHOT from the oss.sonatype.org SNAPSHOTS repository.
The 7.6.10 and 8.1.10 releases are likely going to occur in the first week of March 2013.
Yes, Jetty-7 and Jetty-8 are the same codebase, developed in parallel, and even released in parallel, with the only difference being the servlet spec supported by each. (Jetty-7 is Servlet 2.5, Jetty-8 is Servlet 3.0)
Related
I've run into "application/x-amz-json-1.1" in making requests to AWS resources. Most recently, it became a problem that an API Gateway I was communicating with didn't like handling it (for whatever reason). This got me wondering what the benefit to using application/x-amz-json-1.1 instead of application/json for my requests is. And to my disappointment, AWS doesn't seem to have any documentation on this odd content type.
So I turn to SO: what is "application/x-amz-json" and how is it different from "application/json"?
Amazon does not specifically document what application/x-amz-json Content-Type is for, however there are protocol documentations on Smithy (an open source language for defining services and SDKs published by AWS):
AWS JSON 1.1 protocol
AWS JSON 1.0 protocol
Considering the question relates to the difference when used as Content-Type1 header to make requests, I think we can tell the difference is:
application/json is to request/receive JSON data without anything more specific
application/x-amz-json-1.1 (or other version) is also to request/receive JSON data and expect additional behaviors described in the docs above. (i.e. tell the server/client this is JSON plus additional elements)
I think application/x-amz-json can be thought as a sort of extension or a more specific way of doing application/json requests.
it became a problem that an API Gateway I was communicating with didn't like handling it (for whatever reason)
In the specific case of making PATCH, PUT and POST requests to AWS Amazon API Gateway, specifying Content-Type header application/x-amz-json-1.1 or other version seems to be required. As per related docs:
Content-Type (Conditional)
Specifies JSON and the version, for example, Content-Type: application/x-amz-json-1.0.
Condition: Required for PATCH, PUT and POST requests.
Maybe the server understands application/json as basic JSON but requires application/x-amz-json-1.1 to perform specific requests.
1 Content-Tye header being used to tell the server/client how to process our request
The axios.post request doesn't work without proxy.
I am new in react js and using create-react-app
When I use proxy attribute in package.json and give it my http://url:port in my axios.post I start from /api/...
I do not need any config like headers or allow access. And I don't need to stringy data.
My back-end is java using Apache Tomcat and in back-end I have CORS filter that only allows application/json
requests. When I use postman if the header doesn't match , Apache refuses the request by 415 unsupported media type.
The problem begins from where I want to use npm run build. so there is no package.json and I should bring my full url to axios.post's url part : http://url:prot/api/..
Then I removed the proxy part from package.json
Since that I haven't seen any response from java or even it doesn't refuse the request in http monitoring or Apache Log part (in Netbeans)
I did two small things and something changed!
1-Adding JSON.stringfy before data
2-Adding headers Content-Type:Application/json
Now the request is observable in Netbeans (the back-end) BUT the messege is unsupported media type although i have added to axios.post's config(and itself caused the request received )!!!
there is some thing else : when I use the fire fox CORS enable adds on every things goes grate but only with that...
This is my first project. please explain like I'm 5! I do not know anything more!
Or if someone has any better way; is there any way i can use axios.post without package json proxy?
I'm using Apache HttpClient 4.3.1 and I'm trying to integrate etag validation cache.
I've tried to "drop in" httpclient-cache CachingHttpClientBuilder instead of my usual HttpClientBuilder using instructions in here, but that didn't seem to do any good. While tracing the execution, it seems like a response that has "etag" header (weak etag) isn't considered cache-able - and so isn't retained for the next cycle.
Has anyone managed to use etag validation based cache with Apache HttpClient? I'm also open for alternative implementations.
Notes:
The server returns the first request with a weak etag header (W/"1234"). If the second request to the same URL has "If-None-Match=1234", the server returns 304. This is checked and working.
The server does not send any other cache header (expires, etc).
The whole setup works wonderfully when using a modern browser.
Whether a response is considered as cacheable or not is decided in
ResponseCachingPolicy#isResponseCacheable(org.apache.http.HttpRequest, org.apache.http.HttpResponse)
which checks for some headers using
ResponseCachingPolicy#isExplicitlyCacheable
when
header 'Expires' is set or the header 'Cache-Control:' has one of the values "max-age" "s-maxage" "must-revalidate" "proxy-revalidate" or "public" the response is considered cacheable.
For us, it worked to add "Cache-Control: 'must-revalidate' to the response on the server, along with the 'Etag' header.
With this settings the apache http client
stores the response of the first request in the cache
on the second request, sends a request to the server and if this responds with a HttpStatus 304 (Not Modified) returns a HttpStatus 200 (ok) and the original content to the caller
That is how it should be.
We are using release 4.5.2 of apache http client cache.
I am looking for a way to dump http request & reaponse body (json format) in resteasy on wildfly 8.2.
I've checked this answer Dump HTTP requests in WildFly 8 but it just dumps headers.
I want to see the incoming json message and outgoing one as well.
Can configuration do it without filter or any coding?
Logging HTTP bodies is not something frequently done. That's probably the primary reason for RequestDumpingHandler in Undertow only logging the header values. Also keep in mind that the request body is not always very interesting to log. Think for example of using WebSockets or transmitting big files. You can write your own MessageBodyReader/Writer for JAX-RS, and write to a ByteArrayOutputStream first, then log the captured content before passing it on. However, given the proven infeasibility of this in production, I think your mostly interested in how to do this during development.
You can capture HTTP traffic (and in fact any network traffic) using tcpflow or Wireshark. Sometimes people use tools such as netcat to quickly write traffic to a file. You can use for example the Chrome debugger to read HTTP requests/responses (with their contents).
I put together an applet that uploads images via as3httpclientlib to a servlet. The applet works fine in debug mode (through flash builder) and until today it worked when deployed.
From the servlet logs, it appears the servlet never receives the image(s) byte stream, therefore my hunch is the applet is not posting the multipart data.
Can anyone suggest what I should do next to find the cause of the problem?
I suppose you ran into problem described here:
In Flash Player 10 and later, if you
use a multipart Content-Type (for
example "multipart/form-data") that
contains an upload (indicated by a
"filename" parameter in a
"content-disposition" header within
the POST body), the POST operation is
subject to the security rules applied
to uploads:
The POST operation must be performed
in response to a user-initiated
action, such as a mouse click or key
press.
If the POST operation is
cross-domain (the POST target is not
on the same server as the SWF file
that is sending the POST request), the
target server must provide a URL
policy file that permits cross-domain
access.
So I think you should run your application using debugger and check Flex client logs for exceptions described above.