Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

make it possible to drop pre-RFC2231 variants in C-T and C-D #14

Closed
wants to merge 10 commits into from
Closed

make it possible to drop pre-RFC2231 variants in C-T and C-D #14

wants to merge 10 commits into from

Conversation

rjbs
Copy link
Owner

@rjbs rjbs commented Aug 26, 2022

No description provided.

@rjbs
tests: replace a use_ok with use
b9e34f9 
...because I basically never use use_ok anymore
@rjbs
refactor C-D tests
018e58f 
the primary goal here is to make it possible to add a strict mode
expect, which was not possible in the previous data structure
@rjbs
add c-d tests for strict mode
fcde5b6
@rjbs
add c-t tests for strict mode
11a2717
@pali
Copy link
Contributor

pali commented Aug 26, 2022

just my 2c:

  • "strict mode" is in other modules used for parsing, not for generating output... so it may be confusing
  • "strict mode" is in other modules used for distinguish between "strict" and "loose" mode, where "loose" means RFC-incompatible; but in this module/pullreuqest "strict mode" just controls generation of both foo*0=x and foo=x which is (IIRC) valid according to RFC; this is basically "compatibility mode" for older applications which do not support foo* syntax.

@rjbs
Copy link
Owner Author

rjbs commented Aug 27, 2022

Yeah, I'm not crazy about the name, I just stuck it on there so I could write the code for downstream testing.

I think your second point is a misreading, but doesn't affect the fact that "strict" isn't a great name. This change doesn't affect the generation of foo*0=x, only foo=x. It ensure that there's only one form. While a quick look at the RFC didn't show me that you can't have both, we're seeing problems with both where 2231-form would work.

@pali
Copy link
Contributor

pali commented Aug 27, 2022

This change doesn't affect the generation of foo*0=x, only foo=x. It ensure that there's only one form.

I understand it in this way. Just wrote my previous comment slightly misleading.

Anyway, module already has our $STRICT_PARAMS variable, so new our $STRICT could be confusing. But I really do not know better name. Or maybe reusing $STRICT_PARAMS? No idea what is better.

we're seeing problems with both where 2231-form would work.

Yea, I was expecting that this could be an issue, but during my testing years ago I did not hit this issue. For sure it really makes sense to have an option for generating only foo*0=x form.

marcbradshaw added a commit to fastmailops/mail-dmarc that referenced this pull request Aug 30, 2022
@marcbradshaw
MIME: Use strict mode for Email::MIME::ContentType
118892a 
rjbs/Email-MIME-ContentType#14

This branch is intended to be merged into the fastmail branch only, and
should not be merged to upstream master
@rjbs
Copy link
Owner Author

rjbs commented Sep 2, 2022

@marcbradshaw Behold, the renamed version, which I think is good to go!

@rjbs rjbs changed the title add "strict mode" for creating C-T and C-D make it possible to drop pre-RFC2231 variants in C-T and C-D Sep 4, 2022
@rjbs
update packaging nonsense
cf351f6
@rjbs
mailmap!
96c7090
@rjbs
v1.027
9f173c4 
        - add a (for now undocumented) $PRE_2231_FORM package variable; if set
          to false, when RFC2231-style parameters are used, a pre-RFC2231-style
          version will *not* also be provided; this variable is true by default
marcbradshaw added a commit to fastmailops/mail-dmarc that referenced this pull request Sep 16, 2022
@marcbradshaw
MIME: Use strict mode for Email::MIME::ContentType
9d42ca5 
rjbs/Email-MIME-ContentType#14

This branch is intended to be merged into the fastmail branch only, and
should not be merged to upstream master
marcbradshaw added a commit to fastmailops/mail-dmarc that referenced this pull request Sep 28, 2022
@marcbradshaw
MIME: Use strict mode for Email::MIME::ContentType
ce188ce 
rjbs/Email-MIME-ContentType#14

This branch is intended to be merged into the fastmail branch only, and
should not be merged to upstream master
marcbradshaw added a commit to fastmailops/mail-dmarc that referenced this pull request Sep 28, 2022
@marcbradshaw
build for fastmail
c1a7ef2 
Wed Sep 28 17:33:22 UTC 2022

commit 8985e9a
Author: Marc Bradshaw <marc@marcbradshaw.net>
Date:   Tue Aug 30 05:10:23 2022 +0000

    Tests: dmarc-qa is dead, remove these tests from the fm branch

commit ce188ce
Author: Marc Bradshaw <marc@marcbradshaw.net>
Date:   Tue Aug 30 04:59:42 2022 +0000

    MIME: Use strict mode for Email::MIME::ContentType

    rjbs/Email-MIME-ContentType#14

    This branch is intended to be merged into the fastmail branch only, and
    should not be merged to upstream master

commit 460009b
Merge: 0edd422 5f5ab5e
Author: Marc Bradshaw <marc@marcbradshaw.net>
Date:   Tue Sep 14 11:13:20 2021 +1000

    Merge pull request #2 from fastmailops/SelectorCanBeFalseyFM

    A selector that has a falsey name is dropped

commit 5f5ab5e
Author: Marc Bradshaw <marc@marcbradshaw.net>
Date:   Mon Sep 13 22:28:25 2021 +0000

    A selector that has a falsey name is dropped
@rjbs
Copy link
Owner Author

rjbs commented Jan 9, 2023

This was actually merged and released, just not via these exact commits.

@rjbs rjbs closed this Jan 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@rjbs @pali