> 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
