True! Headers values must be ASCI strings: I thought that the conversion would be done automatically by Rack, but it looks like that's not the case.

I will change the integers to strings directly in the pagy_headers_hash.
Thanks

True! Headers values must be ASCI strings: I thought that the conversion would be done automatically by Rack, but it looks like that's not the case.

I will change the integers to strings directly in the pagy_headers_hash.
Thanks

Thanks, any ETO this be pushed in rubygems?

Sorry for the late answer. I was waiting to add a couple of commits, but it looks like I have no time. Tomorrow I will be able to push 6a93b97

Pushed to Rubygems

Hey !

Thank you @ddnexus and @germanolleunlp

I think it's a good PR but this should be release as a major version because I think it's could be a breaking change for lots of applications.

I'm pretty sure that lots of people calculate their next page by doing something like: Current-Page + 1

With integer, it's an addition like: 1 + 1 => 2

But with string it's a concatenation like so: '1' + 1 => 11

Using parseInt do the job but developers need to be aware of that change more explicitly I think.

Thanks

While this is a considerate concern, it doesn't look like the change can break much if anything at all.

The headers returned to the client were strings before the change and they are still strings after the change, so whatever code was working on the client side will still work.

On the server side the pagy_headers_hash is used internally to return the hash of strings that rack will use to produce the headers. That is not intended to be used in any other ways such as calculations of pages or other stuff: it does the calculations for you.

Of course you can override the method if you want to change its logic... and in that case you are in total control of the calculation and returned values.

The change could in theory break overridden pagy_headers_hash methods that produce some sort of custom headers involving page numbers and calling the original method instead of rewriting it.

Consider that if you need custom headers involving page numbers, you are probably working with an API, and in that case you are probably using the metadata extra, not the standard headers extra.

That complex interaction of coincidences looks like a very remote possibility to me.

But even if that rare case happens, spotting the problem (by running the app just once) and fixing it is so trivial that I could be considered as part of the normal routine adjustment when you upgrade any gem, especially if you overrode something of it.