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.

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

Put original string instead of foldedCase #12

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

lyokha
Copy link

@lyokha lyokha commented Jul 28, 2020

The foldedCase is derivative of the original string, while the latter
is unique. So, putting foldedCase instead of original string leads to
loss of data, while getting from the original string must always restore
CI object correctly as it has been built from the original string.

Probably it should also fix weird cases like in issue #7.

My own case was restoring serialized ResponseHeaders from
Network.HTTP.Types. Say, putting Custom-Header and restoring it later
makes it custom-header (when I take it with original), while when
putting original string it restores correctly as Custom-Header (when I
take it with original).

The foldedCase is derivative of the original string, while the latter
is unique. So, putting foldedCase instead of original string leads to
loss of data, while getting from the original string must always restore
CI object correctly as it has been built from the original string.

Probably it should also fix weird cases like in issue haskellari#7.

My own case was restoring serialized ResponseHeaders from
Network.HTTP.Types. Say, putting Custom-Header and restoring it later
makes it custom-header (when I take it with original), while when
putting original string it restores correctly as Custom-Header (when I
take it with original).
@phadej
Copy link
Collaborator

phadej commented Jul 28, 2020

IIRC my reasoning for using foldedCase is because I wanted to keep a == b -> encode a == encode b property. If your type is really CI a, you shouldn't care about this difference.

Specifically, HTTP headers are case insensitive, thus CI is their type.

@lyokha
Copy link
Author

lyokha commented Jul 28, 2020

Yes, I see the reason. To be precise, equation a == b -> encode a == encode b always holds as far as encoding algorithm must be deterministic, did you mean a == b <-> encode a == encode b? If so, then this invariant does not hold in the current implementation as well when original data is known: the data simply gets lost while being serialized (i.e. encode a == encode b while originally a /= b). The invariant only holds when original data is not known.

Nevertheless, in my case I wanted to forward HTTP headers from a backend to the client, so I wanted to keep them equal (yes, I know that they are case-agnostic, however bad client implementations sometimes matter).

@phadej
Copy link
Collaborator

phadej commented Nov 13, 2021

To be precise, equation a == b -> encode a == encode b always holds as far as encoding algorithm

>>> CI.mk "FOO" == CI.mk "foo"
True

You confuse == for the structural equality. It isn't.

@lyokha
Copy link
Author

lyokha commented Nov 15, 2021

I worked this around by putting original headers in the encoded value and then re-applying mk to them when needed. So, the PR can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants