> > > > It could be even simpler, I think. > > > > * Switch to issuing a POST everywhere that we presently issue a GET, > > with a fallback to GET if the POST is rejected (405) or even better > > based on the api version for mixed system backwards compatibility. > > > > * Switch to accepting both POST and get where we now accept only GET. > > > I'm comfortable with this, and I like the idea of the server being > agnostic about post/get. > > It only gets us halfway, though - we need a POST to return the results > of another query entirely (i.e., the POST of the Facts should return > the results of a GET of a Catalog). How would we do that?
I'm envisioning something much simpler. We presently map requests on to HTTP GETs; instead, we should map them onto HTTP POSTs. That means we've got unlimited payload size in either direction, but otherwise nothing changes. -- Markus P.S. If you want to be real silly and slavishly adhere to the pretense that the RPC -> HTTP mapping is valid, meaningful, and the names line up perfectly you could respond to the POST with a redirection header. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
