On Thu, Nov 6, 2014 at 4:56 AM, Sanford Whiteman <figureone...@gmail.com> wrote:
> > PUT is not intended to necessarily store the request entity body on the > file > > system. Its intention is to store the entity body at the request URI. > > I never said it was. I used the expression "store at the URI" about > 10 ten times on this topic. You are arguing in bad faith by putting > words in my mouth. Stop. > Well, let's not exaggerate. You used the term "store at the request-URI" once in the message from which that reply was intended. However, I was responding to: "What you will get is the entire multipart stored within the filesystem at the mapped URI." Which isn't necessarily true. Albeit the phrasing here can be ambiguous and open to interpretation, because I read it as "the URI maps to the filesystem". The object of the sentence is pretty ambiguous here, but in any case the filesystem itself really has nothing to do with where the data will be stored. It could be stored in a database, or directly on the node accepting the request, or even distributed remotely to other nodes. That part is an implementation detail left up to the server. The point is that the URI signifies the place where the client intends to make the resource available. So the client should be able to retrieve said resource from that URI (or such is the intent). > > In a barebones implementation with just an HTTPd, PUT does mean the > filesystem, which gives an easy example of how incredibly semantically > different it is from POST. Most people do not understand the concept > unless you give them a simple example. > Again, you're getting into implementation details here and deviating away from the specification. There are httpd implementations where PUT does not correlate URI to file system path. I do fully understand the intent of PUT. I can also do without snarky remarks like this where you feel you need to dumb things down as though I have no clue what I"m talking about (like with the LMGTF urls and this feeble attempt at explaining PUT vs. actually focusing on the discussion). I do have some understand of how the web works. I am responsible for working out problems on the web for one of the world's largest sites, after all. So give me some credit. To tackle your point fully, however, you want to keep in mind that you are reading too much into the specification. The spec is laying out the intent of PUT in that the client should be allowed to determine the designated URI where the entity will be stored. This doesn't restrict the media type of the entity in any way. You're assuming that the enclosed entity and the way in which it is stored are disconnected. This is not necessarily true nor is it a part of the specification. Here we just want to ensure two things... 1) That the request URI is the place where client will store the entity 2) That the server cannot decide to change this URI without the approval of the client We can fully meet all of these requirements even if the enclosed entity is infact a multipart mime. There should also be no restriction on the server or end-point decomposing this request in order to better figure out how it should be stored. Just like your email server can inspect headers and decompose the mime to inspect the email for spam/viruses/etc... before figuring out where it should go. It doesn't mean we've broken anything. Just that we've made it easier for PHP users to handle these requests more consistently. For example, perhaps I need check for authentication data, or there are multiple files enclosed in the request (file versioning, for example which is possible in Amazon S3 today). These are important factors you don't seem to be taking into consideration at all. In fact the more you try to dumb down the specification, the less you are sticking to its requirements, because the spec is actually very straight forward and simple. It's describing the client's intent from the request. That's it. Nothing less, and nothing more. We aren't violating that intent if we allow multipart form data to be populated in PHP by this request. > > > So this unfounded claim that decomposition should not happen within PHP > at the request level, isn't a justification for prohibiting PHP from > decomposing the body. > > I made no such claim. I maintain that decomposition not be *required > to happen* within PHP. I couldn't care less if you make it optional > and don't use the $_POST superglobal. I've said this over and over. > Expose the core MIME parser to the user. That'll make it easily used > by frameworks, or via auto_prepend_file. Do not do it automatically > for all requests. > > We are exposing the benefits to the user by populating the super global. Letting userland do the work would make for a less efficient implementation. I'm not seeing any objective reason why we shouldn't do it automatically. Just that you're suggesting we don't. Is there a reason why not? > > For example, if the Content-type designated in the request indicates > application/binary it is safe to say that PHP should not attempt to > disassemble the input stream beyond applying > the decoding from the > Content-encoding header (which may actually happen at the web server > level). However, in this event it would make it a lot more convenient for > the client if the > entity is stored in $_FILES where its access is still > more manageable through the receiving code. > > I noted this case in the other thread and let it be laughed off, but I > actually believe that this is a relatively sensible option, since it > doesn't require any decoding. For that matter, I > ninety-percent-kiddingly wondered if an application/tar body could be > decomposed and its constituent files put into $_FILES, since that's a > case we actually use daily. Again under user control, and not for > every request to a given PHP install, but a kind of pre-superglobal > API would be cool. Of course I know it'll never happen and I'm fine > with that. > I can see that you're opposed to doing things in every request, but is there an actual reason to take existing functionality, and rather than amend it to handle a broader array of requests, simply augment it to diverge off into two separate code paths, where one is optional and the other is mandatory? I'm still having trouble understanding the why. The objection, I've clearly heard, and a 2GB PUT request is not going to lend itself as an argument against when it applies equally to POST. They would both be handled in the same manner (in respect to multipart form data) so how can you say that it's only bad when it's PUT, but it's OK when it's POST if they would exhibit the same behavior? That part just doesn't make any sense to me.
