Remain backwards compatible with X-OCTOBER-REQUEST-HANDLER

[tobias-kuendig]

We just got this PR:
https://github.com/OFFLINE-GmbH/oc-mall-plugin/pull/764/files

I feel like it would be a better solution to keep Winter backwards compatible (look for the "old" and "new" headers) instead of updating all of the plugins that access this header directly.

What are your thoughts on that?

[bennothommo]

@tobias-kuendig yeah, this has been brought up in the Discord. The issue isn't your plugin, it's that we send an X-WINTER-REQUEST-HANDLER instead of an X-OCTOBER-REQUEST-HANDLER.

We can send both, I suppose, but we're trying to avoid the association and infringing on October's trademarks. The intention of those headers were to be "system" headers that weren't used directly by functionality.

I'll bring it up with the team and get back to you. I'll also suggest something with that PR on the Mall plugin to at least remove one of the backwards-incompatibility issues.

[LukeTowers]

The problem with having both for full backwards compatibility is that you now have to send and process two entire sets of headers, as it's not just the X-October-Request header, but every X-October-* header. I feel like accessing the value of these headers directly is not encouraged behaviour, so I'm not sure how many plugins actually do this in the wild besides your specific mall plugin.

As far as "infringing on trademarks" goes with this issue, I'm not so concerned about that, but I am concerned about the performance implications of sending and processing two duplicated sets of headers on every single request; AJAX requests would easily double in size for example.

[bennothommo]

@LukeTowers I was thinking we just transmit (but not read) the X-OCTOBER-REQUEST-HANDLER. It's very, very unlikely people will be manipulating it, they'll just be reading it.

[LukeTowers]

It's somewhat of a slippery slope because people could be sending it for custom implementations of the AJAX framework, along with all the other X-October headers