You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Leif Hedstrom <zw...@apache.org> on 2016/06/30 02:01:39 UTC
Can we remove proxy.config.http.parse.allow_non_http?
(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
Re: Can we remove proxy.config.http.parse.allow_non_http?
Posted by Thomas Jackson <ja...@gmail.com>.
+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 <
sudheerv@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
>
>
>
>
Re: Can we remove proxy.config.http.parse.allow_non_http?
Posted by Thomas Jackson <ja...@gmail.com>.
+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 <
sudheerv@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
>
>
>
>
Re: Can we remove proxy.config.http.parse.allow_non_http?
Posted by Sudheer Vinukonda <su...@yahoo-inc.com.INVALID>.
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
Re: Can we remove proxy.config.http.parse.allow_non_http?
Posted by Sudheer Vinukonda <su...@yahoo-inc.com>.
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