|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
|
|
[jira] Created: (HTTPCLIENT-889) Should USE_EXPECT_CONTINUE be false by default?Should USE_EXPECT_CONTINUE be false by default?
----------------------------------------------- Key: HTTPCLIENT-889 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-889 Project: HttpComponents HttpClient Issue Type: Wish Components: HttpClient Affects Versions: 4.0 Final Reporter: Ren Waldura Priority: Minor It seems the point of USE_EXPECT_CONTINUE is to improve performance when posting large data. http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html says: << The purpose of the 100 (Continue) status (see section 10.1.1) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body. >> There's nothing wrong with HttpClient performing well by default, however, every other HTTP client library I've used does not behave like this (PHP curl, Perl LWP). The default is always to do one request, including the body. Maybe dumb, but simple. It seems to me HttpClient's default behavior should the simplest, most compatible with all HTTP-speaking services out there. "100 Continue" is somewhat advanced, and may not be correctly implemented by all services. (That's of course how I found out about it -- my server doesn't implement it.) If USE_EXPECT_CONTINUE is used only for performance reasons, it seems like it would be simpler (and therefore maybe more "correct") to have it "off" by default. And only enable it when needed, when there is a good reason to. Just my thoughts. And a wish. Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
[jira] Updated: (HTTPCLIENT-889) Should USE_EXPECT_CONTINUE be false by default?[ https://issues.apache.org/jira/browse/HTTPCLIENT-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Kalnichevski updated HTTPCLIENT-889: ----------------------------------------- Fix Version/s: 4.1 Alpha1 In hindsight the decision to turn 'expect-continue' on per default was probably a mistake. There are several reports about various incompatibilities due to poor support of 'expect-continue' by some web servers / proxies. If I hear no objections, I will disable 'expect-continue' per default in 4.1 Oleg > Should USE_EXPECT_CONTINUE be false by default? > ----------------------------------------------- > > Key: HTTPCLIENT-889 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-889 > Project: HttpComponents HttpClient > Issue Type: Wish > Components: HttpClient > Affects Versions: 4.0 Final > Reporter: Ren Waldura > Priority: Minor > Fix For: 4.1 Alpha1 > > > It seems the point of USE_EXPECT_CONTINUE is to improve performance when posting large data. > http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html says: > << The purpose of the 100 (Continue) status (see section 10.1.1) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body. >> > There's nothing wrong with HttpClient performing well by default, however, every other HTTP client library I've used does not behave like this (PHP curl, Perl LWP). The default is always to do one request, including the body. Maybe dumb, but simple. > It seems to me HttpClient's default behavior should the simplest, most compatible with all HTTP-speaking services out there. "100 Continue" is somewhat advanced, and may not be correctly implemented by all services. (That's of course how I found out about it -- my server doesn't implement it.) > If USE_EXPECT_CONTINUE is used only for performance reasons, it seems like it would be simpler (and therefore maybe more "correct") to have it "off" by default. And only enable it when needed, when there is a good reason to. > Just my thoughts. And a wish. Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
[jira] Commented: (HTTPCLIENT-889) Should USE_EXPECT_CONTINUE be false by default?[ https://issues.apache.org/jira/browse/HTTPCLIENT-889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776636#action_12776636 ] Ortwin Glück commented on HTTPCLIENT-889: ----------------------------------------- Yeah, for "small" request entities (such as form data) it doesn't make much of a difference. It's really only useful for a) large request entities, such as image uploads over a low-bandwidth connection b) request entities that are not cached/repeatable, i.e. only producible once (such as streamed data) Judge for yourself if those are "the common" use case for HttpClient. Mind you, reasons why a server would reject a request whose body it hasn't even seen are mainly: - not authenticated - not authorized - content too large - missing content-length information (chunked TE not supported/allowed) - content type not expected/supported > Should USE_EXPECT_CONTINUE be false by default? > ----------------------------------------------- > > Key: HTTPCLIENT-889 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-889 > Project: HttpComponents HttpClient > Issue Type: Wish > Components: HttpClient > Affects Versions: 4.0 Final > Reporter: Ren Waldura > Priority: Minor > Fix For: 4.1 Alpha1 > > > It seems the point of USE_EXPECT_CONTINUE is to improve performance when posting large data. > http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html says: > << The purpose of the 100 (Continue) status (see section 10.1.1) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body. >> > There's nothing wrong with HttpClient performing well by default, however, every other HTTP client library I've used does not behave like this (PHP curl, Perl LWP). The default is always to do one request, including the body. Maybe dumb, but simple. > It seems to me HttpClient's default behavior should the simplest, most compatible with all HTTP-speaking services out there. "100 Continue" is somewhat advanced, and may not be correctly implemented by all services. (That's of course how I found out about it -- my server doesn't implement it.) > If USE_EXPECT_CONTINUE is used only for performance reasons, it seems like it would be simpler (and therefore maybe more "correct") to have it "off" by default. And only enable it when needed, when there is a good reason to. > Just my thoughts. And a wish. Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
[jira] Resolved: (HTTPCLIENT-889) Should USE_EXPECT_CONTINUE be false by default?[ https://issues.apache.org/jira/browse/HTTPCLIENT-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Kalnichevski resolved HTTPCLIENT-889. ------------------------------------------ Resolution: Fixed Fixed in SVN trunk. Oleg > Should USE_EXPECT_CONTINUE be false by default? > ----------------------------------------------- > > Key: HTTPCLIENT-889 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-889 > Project: HttpComponents HttpClient > Issue Type: Wish > Components: HttpClient > Affects Versions: 4.0 Final > Reporter: Ren Waldura > Priority: Minor > Fix For: 4.1 Alpha1 > > > It seems the point of USE_EXPECT_CONTINUE is to improve performance when posting large data. > http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html says: > << The purpose of the 100 (Continue) status (see section 10.1.1) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body. >> > There's nothing wrong with HttpClient performing well by default, however, every other HTTP client library I've used does not behave like this (PHP curl, Perl LWP). The default is always to do one request, including the body. Maybe dumb, but simple. > It seems to me HttpClient's default behavior should the simplest, most compatible with all HTTP-speaking services out there. "100 Continue" is somewhat advanced, and may not be correctly implemented by all services. (That's of course how I found out about it -- my server doesn't implement it.) > If USE_EXPECT_CONTINUE is used only for performance reasons, it seems like it would be simpler (and therefore maybe more "correct") to have it "off" by default. And only enable it when needed, when there is a good reason to. > Just my thoughts. And a wish. Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
| Free embeddable forum powered by Nabble | Forum Help |