Hi,

yes I'm heavily opting for 2) :) you know I initially approved your PR thinking that this should not break any of Sling's users.

Well, today I know that this assumption was wrong. I know of several users which currently rely on the wrong behaviour - and changing it breaks them.

The longer a behaviour exists the more likely it is used by someone.

As there are other means to check for an anonymous request and we have at least one documented and the other one used throughout the code base, I think it is in this case more important to not break our users.
Of course as Jörg pointed out we should somehow document this.

Regards
Carsten

On 20.07.2023 14:37, Konrad Windszus wrote:


On 20. Jul 2023, at 12:53, Carsten Ziegeler <cziege...@apache.org> wrote:

I think there is no one solution fits all here. As always it depends.
Yes, I agree with that. I was referring to this specific use case.

In general we should try to be spec compliant - unless there is a good reason 
not to. There could be different reasons.

In this particular case, imho there is a good reason to not be compliant. We 
have a huge user base and the non spec compliant behaviour is in there for many 
many years. There is a chance that some of our users rely on this behaviour. If 
we change it, we break our users. Which actually happened in this case.
The argument for how long a bug does exist does not matter to much to me TBH, 
let us always strive to improve/fix things.
Also if we break some customer this does not necessarily warrant that we don’t 
fix stuff, if the custom code in this case if clearly relying on spec 
incompatible behaviour.

In addition, in this case if users are trying out our non spec compliant method 
they will immediately see that it is not compliant during development/testing.
Not necessarily this is caught during tests (although I agree it should be). I 
stumbled upon this and it costed me some time to figure this out.
Also this will be reported otherwise again (for good reasons)

But I see, that you are opting for 2) in this case :-)
Konrad

Regards
Carsten

On 20.07.2023 12:28, Konrad Windszus wrote:
Hi,
Carsten just reverted the fix from 
https://issues.apache.org/jira/browse/SLING-11825 in 
https://issues.apache.org/jira/browse/SLING-11974.
The fix is correct according to the Servlet Spec, but it seems some customer 
rely on Sling behaving not spec compliant here.
The question is what weighs more:
1) Spec compliance to make it easier for most new/existing users as otherwise 
behaviour differs from Javadoc and underlying Spec.
2) Backwards compatibility for those users who rely on this spec 
incompatibility.
In my opinion I would clearly go for 1) but I would like to hear other opinions.
Thanks,
Konrad

--
Carsten Ziegeler
Adobe
cziege...@apache.org


--
Carsten Ziegeler
Adobe
cziege...@apache.org

Reply via email to