meaning of browser_preferred API

[HoneyryderChuck]

First things first, great lib! I've been looking for a way to "componentize" facilities for HTTP metadata handling which are now kinda centralized in rack. Good that someone has been having the same forward thinking!

I wanted to question the meaning of the "browser_preferred*" APIs. Is it really something necessary? The way I see it, you expect an env hash, which probably is CGI/Rack API and has nothing to do with browsers, but what if I have an headers container which handles keys in a different way? The Rack/CGI spec maps headers to HTTP_ACCEPT_* envvars/keys, but I can have a container of lowercased headers. (Accept-Encoding-> accept-encoding). This is what net/http does btw.

Of course, the "parse" methods already handle passing the header value. But do those methods have to be loaded with core?

I'm talking p. ex. about https://github.com/ioquatix/http-accept/blob/master/lib/http/accept/encodings.rb#L65-L91

[ioquatix]

I wanted to question the meaning of the "browser_preferred*" APIs. Is it really something necessary? The way I see it, you expect an env hash, which probably is CGI/Rack API and has nothing to do with browsers, but what if I have an headers container which handles keys in a different way? The Rack/CGI spec maps headers to HTTP_ACCEPT_* envvars/keys, but I can have a container of lowercased headers. (Accept-Encoding-> accept-encoding). This is what net/http does btw.

Your absolutely right. Looking at these APIs, they are pretty opinionated and for a specific purpose within the Rack/CGI spec.

The main point of those functions, is to be simple to use.

What we could do... to fix the design without breaking backwards compatibility, is something like:

def self.browser_preferred_charsets(env, field: HTTP_ACCEPT_CHARSET)
	if accept_charsets = env[field]

that way you can override what field would be used.

I'm open for ideas too, so let me know if you have any suggestions :) I really appreciate that you took the time to think about the design and point out a potential flaw.

[ioquatix]

Just for reference, the name of the function "browser_preferred" came from Utopia... (which is where the core parts of this gem were extracted from, originally).

https://github.com/ioquatix/utopia/blob/f3a20844fe16efb030ef3b3354ebc4b782c11707/lib/utopia/localization.rb#L151-L165

The idea is that there are different kinds of preference, browser_preferred_* means based on the request, it was the preference of the client browser. I can see this is actually pretty specific though, it wouldn't necessary be a browser but could be curl, or some other thing.

Perhaps they should be called agent_preferred or client_preferred? Not really sure what makes the most sense.

[HoneyryderChuck]

No worries :) I was looking for ways to parse HTTP headers in this sidelib I'm building, and have been struggling with the many ways header values can be interpreted, that I find myself recycling rack code over and over. I think your gem hits a nice spot, in that it specializes itself in parsing accept headers, where there can be many subvalues, and these can be preferred/selected by "q".

It can benefit both web servers (interested in encoding) and frameworks (interested in language, p. Ex.).

TBH I'd remove those methods / build them in your framework. The method doesn't need an hash, doesn't mutate the hash, you just access a value, and it would work the same way if you'd pass the value as an argument. And logic would be separated from whatever I define as my headers container.

And puff, less code to maintain :)

[ioquatix]

TBH I'd remove those methods / build them in your framework. The method doesn't need an hash, doesn't mutate the hash, you just access a value, and it would work the same way if you'd pass the value as an argument. And logic would be separated from whatever I define as my headers container.

It only accesses one thing.. at the moment, but it's implementation dependent - it might look at other headers in the future if needed to make the correct decision.

And puff, less code to maintain :)

I understand where you are coming from, but as a consumer of this API, it's more code upstream which might make mistakes :D

[HoneyryderChuck]

No worries, just a suggestion. There's enough to fit my needs right now, so it's not a show stopper.

[ioquatix]

@HoneyryderChuck I've started working on a 2.0 release. Now is the time to make breaking changes :p