encoding: parse still spec-incomplete

[HoneyryderChuck]

I've been trying to readapt my accept-encoding specs using this library, and found that some things from the spec aren't implemented. Two stand out for now:

• q=0 aren't being ignored. According to the spec, this means that you explicitly don't want a specific encoding. This is specially valuable for identity.

HTTP::Accept::Encodings.parse("identity;q=0")
# expects #=> []
# returns #=> [#<struct HTTP::Accept::Encodings::ContentCoding encoding="identity", q="0">]

this might have been by design (parse-don't-eval), but in all cases you are creating a needless structure.

• identity isn't explicitly added to the parsing list:

HTTP::Accept::Encodings.parse("gzip;q=1")
# expects #=> [struct gzip, struct identity]
# returns #=> [struct gzip]

again, this might have been intended this way, but as referenced in the case above, sometimes you want to explicitly turn off identity, so you'd have to pass identity in all cases.

This is mostly a reference to the rack specs for encoding. Feel free to ignore this issue if the single purpose is to parse, not evaluate.

[ioquatix]

Thanks for the time you've taken to investigate this issue.

I think this is something we should support.

Part of the library is purely to do with parsing. But, we should also implement logic to support the correct usage of said data structures.

In the same way we have HTTP::Accept::MediaTypes::Map and HTTP::Accept::Languages::Locales, we should probably have something to support the selection of encodings.

It should probably follow the design of HTTP::Accept::Languages::Locales, but it should implement the logic you mention.

What do you think?

[ioquatix]

I'm also open to the idea that .parse should just return the correct structures as you've indicated, but I'm not sure what the best solution is.

[HoneyryderChuck]

I'm mostly commenting in reference to the how rack parses encoding in its specs, i. e. how it handles the edge cases in comparison to this lib. My own routines for encoding selection follow these mostly.

[ioquatix]

I don't completely understand what that helper is doing - the first line seems to be doing nothing?

select_best_encoding would be a candidate for our equivalent browser_best_encoding (naming issues aside).

[HoneyryderChuck]

I think the first line is to ensure that it filters invalid encodings (x not being gzip, compress, etc (?)).

I agree, those are better matching methods, if one has to compare one implementation with the other. That being said, I think that the default identity parameter should be part of the result of calling parse (unless q=0).

Another thing that came to my mind: If the purpose of q parameter is just order by preference, why create a struct proxy to access this value? Wouldn't it be simpler to return the ordered set of encodings?

[ioquatix]

In theory, there can be other parameters.

[ioquatix]

My current feeling is that whatever comes out of parse should be able to recreate what went into parse, but defining what is equivalent, well, that involves semantics.

[ioquatix]

Just to let you know, I'm still interested in improving this. I'm just not sure what the best thing to do is.

[HoneyryderChuck]

I will unfortunately not have time til late August to work on this. However, I'm not sure what to suggest in this case. This library clearly was built to solve your issue, it does, and no matter how this gets generalized, the original motivation might get lost.

I was looking more for an http toolset, nothing more than a few helper functions which help in resolving http semantics and don't have nor need any framework integration.

FWIW, a lot of what I want is inside the rack library, however it is so coupled with rack concepts that it's impossible to use them outside of the rack spec context.

[ioquatix]

It should be possible to add layer of semantics into this.

[ioquatix]

Let me know if you are interested in working on this. I think we should probably consider a semantic layer on top of the parser. I would be absolutely happy for a semantic layer to discard q=0 entries, and do any other form of processing that makes sense for an application layer.

[ioquatix]

@HoneyryderChuck Just wondering if you had any time to think about this?

[HoneyryderChuck]

@ioquatix I still find it hard to add my desired changes without breaking compatibility. Also, I've been quite out of time lately.

[ioquatix]

I'm planning to revisit this issue, and I'll release a major revision (e.g. 2.x) to adjust the API. Let me know if you have time to provide input.