Add Cookies and Queries list

[alexander-schranz]

References

• https://github.com/TYPO3/typo3/blob/569ee47af1c133a536c35a31a6321258912bdfe8/typo3/sysext/core/Configuration/DefaultConfiguration.php#L1387-L1444
• https://github.com/contao/contao/blob/5.x/core-bundle/src/EventListener/HttpCache/StripCookiesSubscriber.php
• https://github.com/contao/contao/blob/5.x/core-bundle/src/EventListener/HttpCache/StripQueryParametersSubscriber.php

Open Questions

• A: List of Regex or Strings?
• B: Static methods or service with interface?
• C: Naming Namespace, classes and methods
  • Classes:
    • Queries, QueryList, Query, ...
    • Cookies, CookieList, Cookie, ...
  • Method:
    • getList, get, Query, ...
  • Namespace:
    • PhpCmsig\HttpList, Cmsig\HttpList, ...
• D: Composer Package Name / Repository Name
  • php-cmsig/http-list, cmsig/http-list, ...
• E: Supported PHP Version
• F: ...

TODO

• Finish list (currently one list uses regex one string both should work the same way)
• Add Coding Standard
• Add License Header
• Tests, Specially if we go with regexes instead of list of strings

[Toflar]

LGTM! I think we need regex because some of the names contain random numbers or identifiers.

What we imho also need then is the basic regex and correct escaping and quoting. And maybe we can provide a shortcut for Symfony's request class. It's so common that it imho qualifies for that (we can also add PSR, if anybody does the work of course).

Regarding the naming: I have no clue how to name this properly. It's a list of data you usually don't want to have on the server side :D But only relevant for caching. So maybe HttpCacheStripList 🤔

[alexander-schranz]

@Toflar yeah I think that would make sense, would you put it into the same class all? Or seperate classes for HttpFoundation and PSR7 strip?

[Toflar]

Hmm, probably in separate classes. Separation of concerns and stuff :)

[chirimoya]

Regarding the naming: I have no clue how to name this properly. It's a list of data you usually don't want to have on the server side :D But only relevant for caching. So maybe HttpCacheStripList 🤔

It's not only about caching, e.g. the canonical url should also ignore the irrelevant query parameters.

[alexander-schranz]

I'm thinking about moving SEAL also to cms-fig namespace (but let that point discuss in Slack) What I want to discuss here is what namespace we want to use for our cooperation packages:

PHP Namespace

• PHPCMSig\HTTPList / PHPCMSig\SEAL
• CMSig\HTTPList / CMSig\SEAL
• CMS\HTTPList / CMS\SEAL
• PhpCmsig\HttpList / PhpCmsig\Seal
• Cmsig\HttpList / Cmsig\Seal
• Cms\HttpList / Cms\Seal

Correctly camelcased things like HTTP, CMS, SEAL would be Http, Cms, Seal so the choices would be, but I'm open here for suggestions:

• PhpCmsig\HttpList / PhpCmsig\Seal
• Cmsig\HttpList / Cmsig\Seal
• Cms\HttpList / Cms\Seal

Composer / Packagist Namespace:

• php-cmsig/http-list / php-cmsig/http-list
• cmsig/http-list / php-cmsig/http-list
• cms/http-list / cms/seal not sure if that is may blocked by packagist currently

Maybe @Seldaek can tell us if cms would be availabe for a cooperation namespace used as for cooperation packages between different CMS systems (currently @contao, @sulu, @TYPO3).

I personally would find Cms\Namespace and cms/package-name interresting to use for our cooperation.

[Seldaek]

I think from my side yes I could grant you access to cms/ vendor, but cmsig would be more sensible IMO as less generic.

[alexander-schranz]

@Seldaek Thank you for the response think then we will go with cmsig.

My suggestions so would be:

PHP Namespace: CmsIg -> CmsIg\Seal, CmsIg\HttpList
Composer Namespace: cmsig -> cmsig/seal, cmsig/http-list
Plugin/Bundle/Extenstion Name: cmsig -> cmsig_seal