How to turn off Transfer-Encoding: Chunked when sending with jetty client

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

How to turn off Transfer-Encoding: Chunked when sending with jetty client

Tuomas Kiviaho
Hi,

Is there a way to turn off chunking when sending with jetty client. HttpConnection.normalizeRequest contains a section where chunked transfer encoding is enforced when content provider length is not specified.

If I skip the normalization then the HttpGenerator.generateRequest->generateHeaders insist on falling back to chunked encoding because Connection: close doesn't avoid this fall back procedure because response(?) is missing. I just set end-of-content despite missing response (it's request after all that I'm generating) then the connection is (eventually) marked as non-persistent and chunking is avoided.
Reply | Threaded
Open this post in threaded view
|

Re: How to turn off Transfer-Encoding: Chunked when sending with jetty client

Simone Bordet-3
Hi,

On Mon, Nov 16, 2015 at 2:04 PM, Tuomas Kiviaho <[hidden email]> wrote:

> Hi,
>
> Is there a way to turn off chunking when sending with jetty client.
> HttpConnection.normalizeRequest contains a section where chunked transfer
> encoding is enforced when content provider length is not specified.
>
> If I skip the normalization then the
> HttpGenerator.generateRequest->generateHeaders insist on falling back to
> chunked encoding because Connection: close doesn't avoid this fall back
> procedure because response(?) is missing. I just set end-of-content despite
> missing response (it's request after all that I'm generating) then the
> connection is (eventually) marked as non-persistent and chunking is avoided.

I don't understand, sorry.

If you want to avoid chunking, just specify the Content-Length.

If you don't have the content length, and you want to force the
request content to be delimited by the connection close, just use
HTTP/1.0 rather than 1.1.

--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: How to turn off Transfer-Encoding: Chunked when sending with jetty client

Greg Wilkins
In reply to this post by Tuomas Kiviaho

Connection:close cannot be used to delineate the content of a request (as it can be for a response), because some infrastructure does not well support half closed connections - thus the RFC explicitly disallows this.

So content-length is the only way to avoid chunking in a request.


On 17 November 2015 at 00:04, Tuomas Kiviaho <[hidden email]> wrote:
Hi,

Is there a way to turn off chunking when sending with jetty client.
HttpConnection.normalizeRequest contains a section where chunked transfer
encoding is enforced when content provider length is not specified.

If I skip the normalization then the
HttpGenerator.generateRequest->generateHeaders insist on falling back to
chunked encoding because Connection: close doesn't avoid this fall back
procedure because response(?) is missing. I just set end-of-content despite
missing response (it's request after all that I'm generating) then the
connection is (eventually) marked as non-persistent and chunking is avoided.



--
View this message in context: http://jetty.4.x6.nabble.com/How-to-turn-off-Transfer-Encoding-Chunked-when-sending-with-jetty-client-tp4964913.html
Sent from the Jetty User mailing list archive at Nabble.com.
_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users



--

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: How to turn off Transfer-Encoding: Chunked when sending with jetty client

Tuomas Kiviaho
Greg Wilkins wrote
Connection:close cannot be used to delineate the content of a request (as
it can be for a response), because some infrastructure does not well
support half closed connections - thus the RFC explicitly disallows this.
Thanks for clearing this one out for me. There it is at at index number 6 on RFC 7230 http://greenbytes.de/tech/webdav/rfc7230.html#message.body.length. I guess the comments in the source code were back from the day of RFC 2616.

HTTP/1.0 suggested earlier doesn't sound appealing, but at least that's still a sort of an option. I am sending text/event-stream with the jetty client so the chunking sort of caught my eye.

PS. You asked uses cases couple a months back at http://stackoverflow.com/questions/30904782/use-cases-for-reactive-streams-using-java-9-flows-in-servlets and plain old SSE processing could be one. The servlet jetty provides for SSE seems a bit outdated now that I saw what you've playing with.

--
Tuomas Kiviaho
Reply | Threaded
Open this post in threaded view
|

Re: How to turn off Transfer-Encoding: Chunked when sending with jetty client

Simone Bordet-3
Hi,

On Fri, Nov 20, 2015 at 8:22 AM, Tuomas Kiviaho <[hidden email]> wrote:

> Greg Wilkins wrote
>> Connection:close cannot be used to delineate the content of a request (as
>> it can be for a response), because some infrastructure does not well
>> support half closed connections - thus the RFC explicitly disallows this.
>
> Thanks for clearing this one out for me. There it is at at index number 6 on
> RFC 7230  http://greenbytes.de/tech/webdav/rfc7230.html#message.body.length
> <http://greenbytes.de/tech/webdav/rfc7230.html#message.body.length>  . I
> guess the comments in the source code were back from the day of RFC 2616.
>
> HTTP/1.0 suggested earlier doesn't sound appealing, but at least that's
> still a sort of an option. I am sending text/event-stream with the jetty
> client so the chunking sort of caught my eye.
>
> PS. You asked uses cases couple a months back at
> http://stackoverflow.com/questions/30904782/use-cases-for-reactive-streams-using-java-9-flows-in-servlets
> <http://stackoverflow.com/questions/30904782/use-cases-for-reactive-streams-using-java-9-flows-in-servlets>
> and plain old SSE processing could be one. The servlet jetty provides for
> SSE seems a bit outdated now that I saw what you've playing with.

Can you expand on what you mean by "outdated" ?
You mean that you would prefer a ReactiveStreams API for SSE rather
than the API that is provided ?
Are you using https://github.com/eclipse/jetty.project/blob/master/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/EventSourceServlet.java
?

Also you said you are sending text/event-stream from the *client* ?

--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: How to turn off Transfer-Encoding: Chunked when sending with jetty client

Tuomas Kiviaho
Simone Bordet-3 wrote
Can you expand on what you mean by "outdated" ?
You mean that you would prefer a ReactiveStreams API for SSE rather
than the API that is provided ?
Are you using https://github.com/eclipse/jetty.project/blob/master/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/EventSourceServlet.java
?

Also you said you are sending text/event-stream from the *client* ?
I guess "outdated" was a bit harsh, because the EventSource.Emitter API is quite piece of an equipment. It only misses minor details like id/comment/retry and possibility to have better control over flushing, but those could easily be added to it.

I've patched EventSourceServlet to use javax.servlet.WriteListener to have control over throttling. The original EventSource API hid the javax.servlet quite nicely, but I was thinking about using ReactiveStreams adapter to hide WriteListener. So the Emitter API combined with ReactiveStreams would suit me well.

I'm also sending text/event-stream and using the Emitter API the other way around as awful as it may sound. Of course the rest of the RFC itself is quite meaningless because it revolves around the response, but the content type is as good as any and http clients DeferredContentProvider works like a charm with it. Chunking here it merely an annoyance that just makes alignment of the incoming bytebuffers even more non-optimal for the ReadListener. ReactiveStreams is a good way to hide the javax.servlet again and I'm even using the Emitter API to receive data.