+1 to removing (and setting default to 0)
If we get to the point of getting protocol plugins back (so that we can
support non-http) -- we should make this check pluggable per
protocol-plugin, but since that isn't whats happening-- we can just remove
this one.
On Wed, Jun 29, 2016 at 9:20 PM, Sudheer Vinukonda <
sudhe...@yahoo-inc.com.invalid> wrote:
> blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px
> #715FFA solid !important; padding-left:1ex !important;
> background-color:white !important; } I think this config was introduced to
> ensure "backward" compatibility, since we wanted to block/reject non HTTP
> responses, but the default behaviour was to allow them (hence, the default
> setting of "1" as well).
> I'd vote to remove the option and make the behaviour assume "0" setting
> (fail parsing of non HTTP responses). It's unlikely this would break
> anything, although I couldn't be 100% certain.
> Thanks,
> Sudheer
>
>
>
>
>
>
> On Wednesday, June 29, 2016, 7:01 PM, Leif Hedstrom <zw...@apache.org>
> wrote:
>
> (This is discussed in https://issues.apache.org/jira/browse/TS-4405).
>
> This option, proxy.config.http.parse.allow_non_http, allows the response
> parser to not require HTTP/n.m in the response. I don’t know when this is
> useful any more, likely this is a remnant from either old servers, or old
> protocols.
>
> It is by default on (weird?), and is undocumented.
>
> Now, the questions are:
>
> 1) Do we need to keep this option?
>
> 2) Is the default “1” actually reasonable? If we disabled it, what would
> we break? Anything?
>
> 3) If we removed the option, do we make the logic assume the current “1”
> behavior, or the “0” behavior?
>
> Thoughts?
>
> — leif
>
>
>
>
