Disabling STRICT_HTTP config option it will be compiled with "--disable-http-violations". I need active STRICT_HTTP to use http violations. It doesn't make sense. Makefile ports: ------------------- STRICT_HTTP_CONFIGURE_ENABLE= http-violations ------------------- Squid: Squid33-3.3.11_6 FreeBSD: FreeBSD home.xxxxxxx 10.0-RELEASE FreeBSD 10.0-RELEASE #3: Sun Aug 24 04:31:32 BRT 2014 root@home.xxxxxx:/usr/src/sys/i386/compile/HOME i386 I suggest change "STRICT_HTTP" to "NO_STRICT_HTTP", that will be compatible with other config options internally.
maybe takefu has an opinion...
To be honest, I don't understand the problem. --enable-http-violations is default option in squid's configure unless the --disable-http-violation is presented. If STRICT_HTTP is marked the --enable-http-violations is used. If STRICT_HTTP isn't marked the --disable-http-violations is passed to configure. Try to mark or unmark it, make and then look in work/squid-3.3.11/config.log.
(In reply to timp87 from comment #2) > To be honest, I don't understand the problem. > > --enable-http-violations is default option in squid's configure unless the > --disable-http-violation is presented. This is incorrect. It's not default, both are explicit. --disable is passed if the option is not enabled.
(In reply to John Marino from comment #3) > (In reply to timp87 from comment #2) > > To be honest, I don't understand the problem. > > > > --enable-http-violations is default option in squid's configure unless the > > --disable-http-violation is presented. > > This is incorrect. It's not default, both are explicit. --disable is > passed if the option is not enabled. Ok, I agree. But other stuff seems ok: > If STRICT_HTTP is marked the --enable-http-violations is used. > If STRICT_HTTP isn't marked the --disable-http-violations is passed to configure. > > Try to mark or unmark it, make and then look in work/squid-3.3.11/config.log.
The point is if mark STRICT_HTTP so it's not http violation (--disable-http-violation). Right? Actualy if mark that option set to --enable-http-violation.
(In reply to screenblack from comment #5) > The point is if mark STRICT_HTTP so it's not http violation > (--disable-http-violation). Right? > > Actualy if mark that option set to --enable-http-violation. Ah, understood, sorry. http with violations is not strict :). I agree.
(In reply to screenblack from comment #5) > The point is if mark STRICT_HTTP so it's not http violation > (--disable-http-violation). Right? > > Actualy if mark that option set to --enable-http-violation. screenblack, can you propose a patch so that it's crystal-clear what the fix is?
I suggest change make config expression "STRICT_HTTP Make Squid strictly HTTP Compliant" to "NO_STRICT_HTTP Make Squid HTTP violations mode" Or something like that. :) Using that form doesn't need to change internaly, just keeping "--enable" and "--disable" options. What do you think?
Created attachment 146254 [details] name HTTP_SCRIPT option more logical Maybe this like?
Perfect! Thank you
all you did was change the name of the option. We have to come up with a better name than "NOT_STRICT". I don't like negated options.
"HTTP_VLTN" maybe?
Created attachment 146259 [details] Clarify strict HTTP option I was thinking along these lines instead. I also moved OPTIONS_DEFAULT next to OPTIONS_DEFINE, it's conventional location.
(In reply to John Marino from comment #13) > Created attachment 146259 [details] > Clarify strict HTTP option > > I was thinking along these lines instead. > > I also moved OPTIONS_DEFAULT next to OPTIONS_DEFINE, it's conventional > location. Ok
A commit references this bug: Author: marino Date: Mon Aug 25 17:54:19 UTC 2014 New revision: 366115 URL: http://svnweb.freebsd.org/changeset/ports/366115 Log: www/squid33: Clarify option for http-violations The option STRICT_HTTP was highly misleading. If enabled, it disabled strict checking, the opposite of what somebody would reasonably assume. Rename the option to LAX_HTTP and improve the description to ward off potential confusion. PR: 192980 Reported by: screenblack (gmail) Changes: head/www/squid33/Makefile
Hopefully everything is clear now.
There should be a note that this option that used to be enabled by default is now disabled by default, so that people wondering why their configuration that worked with 3.3.11_4 stopped working with PORTREVISIONS after this. Up to 3.3.11_4 enabling STRICT_HTTP ==> --disable-http-violations. So OPTIONS_DEFAULT of not setting this, mean http-violations were enabled. In _5 it was changed to *CONFIGURE_ENABLE=, inverting the behavior and inverting the previously inverted logic. So, not setting STRICT_HTTP suddenly meant 'strict_http' was set (as it would disable http violations.) Changing the name to LAX_HTTP clarified the relationship of the options knob to the configure option, but did not restore the previous default behavior that it was enabled. Or make clear that this was needed to restore things to previous defaults. I have refresh_patterns that violate HTTP to try to make our squid proxies keep files relating to updates for Microsoft, Linux and FreeBSD in cache longer....
(In reply to Lawrence Chen from comment #17) > There should be a note that this option that used to be enabled by default > is now disabled by default, so that people wondering why their configuration > that worked with 3.3.11_4 stopped working with PORTREVISIONS after this. This is untrue. The labeling changed. The option value did not change. It will built exactly as before. > > Up to 3.3.11_4 > > enabling STRICT_HTTP ==> --disable-http-violations. So OPTIONS_DEFAULT of > not setting this, mean http-violations were enabled. > > In _5 it was changed to *CONFIGURE_ENABLE=, inverting the behavior and > inverting the previously inverted logic. So, not setting STRICT_HTTP > suddenly meant 'strict_http' was set (as it would disable http violations.) Again, no behavior was inverted. It's the same defaults as before. Had it been inverted, I would have bumped the port revision. > > Changing the name to LAX_HTTP clarified the relationship of the options knob > to the configure option, but did not restore the previous default behavior > that it was enabled. Or make clear that this was needed to restore things > to previous defaults. I don't know what you mean. Previous to what? I am talking relative to the state it was in before the commit. There is no behavior change.
ah wait, one option removed and a new one added. It did need a revbump. But not anymore, the port has been updated since then to a new version.
(In reply to John Marino from comment #18) > > > > Changing the name to LAX_HTTP clarified the relationship of the options knob > > to the configure option, but did not restore the previous default behavior > > that it was enabled. Or make clear that this was needed to restore things > > to previous defaults. > > > I don't know what you mean. Previous to what? I am talking relative to the > state it was in before the commit. There is no behavior change. Compared to the previous commit that changed the default behavior, then yes there is no change in behavior. But, needing the clarify an option because the prior commit inverted its behavior, and as a result inverted the previous default build configuration, is the problem. It means anybody upgrading from squid33 3.3.11_4 or older may see an unexpected change, it may also stop people from upgrading from squid32 due to this change.
(In reply to Lawrence Chen from comment #20) > But, needing the clarify an option because the prior commit inverted its > behavior, and as a result inverted the previous default build configuration, > is the problem. It means anybody upgrading from squid33 3.3.11_4 or older > may see an unexpected change, it may also stop people from upgrading from > squid32 due to this change. All the squid ports were in terrible, awful shape. I actually doubt many people were using squid32. They'd probably stayed on www/squid or already be on squid33. In any case, it's moot. In 2 weeks anyone on those two ports are going to have to move (or wait until squid34 moves to www/squid soon after). I don't know how serious of an issue this is, but my initial feeling is "not very". Every time the options change, you get the option menu again, so it's not a silent change. Finally, you can't make an omelet without breaking some eggs and that might have happened here. www/squid33 is finally not offensive to took at, it's come a lot way in a couple of days in a group effort. So sorry about the inconvenience, it's to better serve in the future. (think mall construction signs)