On Jan 27, 2011, at 9:25 AM, Jason Brower wrote: > > I wonder if there is an example where this could be an advantage for us?
The change was driven by a report that /a/c/f/arg and /a/c/f/arg/ generated different request.args lists, when we ordinarily expect a trailing slash to be ignored. The primary motivation was to have *some* definite spec for how empty args should be handled, and the resolution was the spec below: strip trailing slashes, but otherwise permit empty args items. It's not the only possible resolution, but it seems reasonable. If an application is counting on trailing empty args (by 'empty arg' I mean an arg with a value of an empty string, ''), it will have to interpret missing args at the end of the list as empty. In the past, empty args were treated as errors, except for the case of a single trailing slash. > BR, > Jason > > On Wed, 26 Jan 2011, Jonathan Lundell wrote: > >> This applies to both the old and new URL rewrite paths, regardless of >> whether there's any rewriting going on. >> >> Previously, a trailing slash after args would cause an extra arg to be added >> to the list with a value of '' (empty string). In the old logic, an embedded >> empty arg was illegal. >> >> That is: >> >> /a/c/f/arg1 >> >> gave args as ['arg1'] >> >> /a/c/f/arg1/ >> >> gave args as ['arg1', ''] >> >> /a/c/f/arg1//arg2 >> >> was illegal. >> >> Now, trailing slashes are stripped, so the first two examples about give >> ['arg1'], as does /a/c/f/arg1///// >> >> Also, embedded empty args are legal, so the arg2 example above yields ['', >> 'arg2'] >> >>
