#pyramid

domenkozar: I'm interested to hear what you folks will be doing

raydeo: So, your suggestion is that content negotiation should be avoided?

I think after reading the RFC that it's a pretty broken system

hmm

accept handling has come up often in pyramid and each time it's been clear that a) pyramid is not doing the wrong thing and b) it's usually not doing what people want it to do

there's a few possible improvements that could be made but no one has been willing to work through it enough to submit a real PR

raydeo: theres nothing settled yet besides the two major topics, as far as I know.

I'd be happy to work on it this weekend if there is some doc on what the expectation is

domenkozar: ok I'm just kinda curious as the guy that's doing like 90% of actual code (non-docs) changes to pyramid these days what people may have in mind that aren't on my radar

monokrome: we'd probably have to chat about the details a bit more, and with x58 in the room but I'm happy to do that

cool :)

raydeo: The main two sprint topics are Pyramid 2.0 and Pyramid for Newcomers.

I assume the latter is more docs oriented

pyramid 2.0 isn't actually a thing so definitely interested to find out what that means :-)

anyway looking forward to it!

probably more like 1.8 :)

Pyramid.next

raydeo: tbh I've been absent for a while so I'm a bit out of the loop and rely on others that work with pyramid on daily basis to provide feedback :-)

Seems like Googlebot sends */* as well

I'm using https://haskell-servant.github.io/ these days :)

domenkozar: understandable - as far as pyramid 1.8 I'm pretty much itching to release that one but would be awesome if someone gets something done to include

I thought you were using elm these days

haskell on backend

you specify the whole api with types

then you can generate things like elm types and requests out of it

or docs, etc

think swagger with types.

sounds nifty

Ugh... accept handling.

I've written books about that shit on the Pyramid bug tracker...

I've got a bunch of half-assed solutions hacked together for Pyramid, none that workin all situations.

That being said, I built an explicti_accept predicate that allows me to explicitly check that a content-type is listed in the accept header (i.e. it throws */* out to match against)

Now I can use accept="text/html" and always return that in the case of */* and use explicit_accept="application/json" when I want to explicitly have a view match when application/json is in the accept header.

Works well for JSON API's

We can have a discussion on it... but before doing so, please track down the issues in the GH issue tracker...

it seems to me most issues would be solved if you could tag a particular accept with a server-side weight (maybe even without doing scary multiplication of weights)

That's something I considered

your solution sounds exactly like people expect, fwiw

I had a branch for that somewhere.

x58: That's what I was thinking of doing for it

monokrome: what part?

The predicate

That works fine, use it. Just can't use that to fix the issue for Pyramid as a whole.

Because it changes the way things work.

raydeo: Weighting is something we discussed here on-channel a while back. You were heavily against it at the time.

There was a patch that someone had proposed that made it dependent on insertion order, which doesn't work with .scan(), so that was out too.

I don't remember why but it was probably due to the unstable multiplication

So that multiplication stuff is actually defined in the RFC for content negotiation and is how Apache does it's content negotiation.

Here's some information on content negotiations: https://github.com/Pylons/webob/issues/239

Even with the multiplication stuff, if I added best_client_match the behavior for Accept handling in Pyramid would be somewhat sane.

So add this: https://github.com/Pylons/webob/pull/241

and then add weighting to what Pyramid allows in the accept= option to the view_config

with best_client_match I think pyramid requires no changes to accept=

Use best_client_match with the newly weighted accept entries, and voila

You'd still want weighting for the */* case

you just wouldn't define accept='*/*'

you'd want it as a fallback if nothing matched

so a fallback view with no accept

The client sends */* so you'd want weighting server side to make sure that text/html gets sent back out.

hmm, right

client_best_match still checks for */* it doesn't strip that out.

So if the server had application/json, text/html then application/json would win for best_client_match

So you'd want application/json;q=0.9, text/html;q=1

server side to allow text/html to win.

so are we still talking about like... accept=('text/html', 2.0)

or a q= syntax

Yep, except numbers are from 0 -> 1 only, no 2.0

WebOb already understands the q= syntax for server side.

IIRC.

would we set the default at 0.5 or something?

Nope, set the default at 1.0

Well

x58: The issue with the predicate is that Pyramid seems to think all configurations are the same if they don't define an `accept` here :D

ideally you only annotate the default view... not every view

with a quality I mean

raydeo: I could be convinced either way. i prefer being explicit over being implicit

but q=0.5 would work just fine.

I don't like the idea of having to specify a q= on every view

I mean just from a usability perspective

monokrome: I am not sure what you are talking about.

raydeo: Setting q=0.5 shouldn't make a difference if that were the default

then if you had accept="text/html" and a accept="application/json" they would both still be weighted the same

and it would depend on insertion order (which IMHO, we should just sort() and then that goes out the window so that users don't think insertion order matters)

x58: EG, it seems to think these are "conflicting" configurations: https://gist.github.com/monokrome/3f966fe88b80d...

monokrome: Those should be two different views, make sure your explicit_accept has a hash that is different for the two of them.

is the phash not accounting for the value?

Should have a phash, I set mine to text which has the value in it.

x58: ooooh, yep :)

thanks

raydeo: I wouldn't mind dropping best_client_match into WebOb 1.7, if you think it is useful for Pyramid.

really don't know atm

I need to get some stuff out the door and shipped. Will be back later, we can discuss further if you'd like.

it seems not crazy though

The RFC just doesn't say what servers should do if there are two representations of the same resource with the same weights and the client doesn't care.

gavinc: Read the WebOb issue I linked to, the RFC leaves a lot to be desired, that is only one part of it.

Yeah, just read it

the RFC only defines client/server interaction really

Apache weights it by the order the files are read from disk ;-)

Yep.

Even that it doesn't do a good job of.

apache 1.3 did it by always prefering text/* ;)

Reading from disk can provide weird results, certain file systems don't return alphabetically sorted file lists for example (/me looks at Solaris with UFS)

but the same server will tend to return the same answer

Yeah, Apache has a bunch of different hacks and interpretations.

raydeo: mull it over, I'm game :-)

q=1.0 just doesn't seem to indicate properly what we want

yeah q=1 as a default is a bad idea

since it makes prioity with any default accept imposible

I'm not sure I like server-side q= support

it makes me think we should support a full accept string

in reality we just want to focus on a single content-type pattern

There should be some way to express the way for the application to resolve two representations of the same resource and the client hasn't bothered to tell it which one it wants

accept=('application/json', 2.0), not accept='application/json;q=0.8 text/html;q=0.5'

OR throw a warning (Client is crazy! Can't tell what it wants)

by liberal in what you accept ;-)

be*

pun intended

So the conserivite thing might be to always prefer text responces ;)

responses too

does anyone besides me lose sleep over the fact that ie accepts images higher than html

sorry not higher... I meant further left... which of course doesn't mean anything in the rfc

but best_client_match would be assigning such meaning I think

raydeo: I did once. It got better after not being on any W3C working groups ;)

I could never do such a masochistic thing

but but the great rewards! ... of having random people email you questions years later that are answered in the document you spent 2 years writing ;)

So something to consider is if the default handing for accepts that match two views content type equally really needs to view/route specific

Might be simpler to provide a default text before app, app before image, whatever and allow that to be configured?

I think it's difficult to nail down the resolution algorithm we actually want here

currently it's pretty easy... you take all view-accepts and throw them into accept.best_match() which uses the client quality to return one of the server's options