Le 05/11/2014 00:58, Andrea Faulds a écrit :
Good evening,
A lot of RFCs have been rejected because, while they proposed a feature people
would like, the details were problematic. This has lead to these features
sometimes being considerably delayed.
So, in order to do something about this,
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Wednesday, November 05, 2014 1:59 AM
To: PHP internals
Subject: [PHP-DEV] RFC Process: Should we hold two different votes?
Why not hold two
different votes on an RFC, similar to how legislation is passed in the UK’s
On Wed, Nov 5, 2014 at 9:35 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Wednesday, November 05, 2014 1:59 AM
To: PHP internals
Subject: [PHP-DEV] RFC Process: Should we hold two different votes?
Why not hold two
different
On 4 November 2014 18:14, Rowan Collins rowan.coll...@gmail.com wrote:
On 3 November 2014 22:45:11 GMT, Chris Wright daveran...@php.net wrote:
Good evening list,
I'd like to open discussion a relatively simple and clear-cut RFC,
either
people will like it or they won't, there isn't a lot
Hi Dmitry
On 4 November 2014 20:13, Dmitry Stogov dmi...@zend.com wrote:
I like the idea, especially list($a, $b, ...$c) = ...
Looks like Prolog's [A, B | C] = ..., unfortunately it won't provide the
same semantic and performance.
Implementation needs to be reviewed, but I think it must not
Before you fall of your chairs let me expand on that ...
Many of the sites I'm supporting are being chased by the we want your
work mob, and being told they Must have apps to stay in business. Of
cause that means both an android and an apple one with a discount on the
pair. BUT in most cases a
Hi,
On Wed, Nov 5, 2014 at 11:57 AM, Lester Caine les...@lsces.co.uk wrote:
Before you fall of your chairs let me expand on that ...
Many of the sites I'm supporting are being chased by the we want your
work mob, and being told they Must have apps to stay in business. Of
cause that means
On 5 November 2014 10:57, Lester Caine les...@lsces.co.uk wrote:
Before you fall of your chairs let me expand on that ...
Many of the sites I'm supporting are being chased by the we want your
work mob, and being told they Must have apps to stay in business. Of
cause that means both an android
On 4 November 2014 18:14, Rowan Collins rowan.coll...@gmail.com wrote:
If anything, I think I would expect the keys of splatted arrays to be
discarded, since it seems most natural to use this in a list context, but I
can imagine always having to check in the manual.
I agree on this point.
On 5 Nov 2014, at 11:14, Leigh lei...@gmail.com wrote:
On 5 November 2014 10:57, Lester Caine les...@lsces.co.uk wrote:
Before you fall of your chairs let me expand on that ...
Many of the sites I'm supporting are being chased by the we want your
work mob, and being told they Must have
On 5 November 2014 11:22, Leigh lei...@gmail.com wrote:
On 4 November 2014 18:14, Rowan Collins rowan.coll...@gmail.com wrote:
If anything, I think I would expect the keys of splatted arrays to be
discarded, since it seems most natural to use this in a list context, but I
can imagine
Hi Levi,
The patch is here https://gist.github.com/dstogov/8deb8b17e41c1a5abf88
I improved memory consumption and unified return type-hinting error
behavior with existing argument type-hinting.
The main semantic must be unchanged.
I also removed part of Reflection changes. I think we should
On 5 Nov 2014, at 11:53, Dmitry Stogov dmi...@zend.com wrote:
Hi Levi,
The patch is here https://gist.github.com/dstogov/8deb8b17e41c1a5abf88
I improved memory consumption and unified return type-hinting error
behavior with existing argument type-hinting.
The main semantic must be
On 05/11/14 11:29, Andrea Faulds wrote:
On 5 Nov 2014, at 11:14, Leigh lei...@gmail.com wrote:
On 5 November 2014 10:57, Lester Caine les...@lsces.co.uk wrote:
Before you fall of your chairs let me expand on that ...
Many of the sites I'm supporting are being chased by the we want your
Hi Guilherme,
On 4 November 2014 23:47, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Sorry, I forgot to add references to how we fixed emails handling. It got
split in 2 places:
- Initial root level annotation
On 5 Nov 2014, at 14:02, Marco Pivetta ocram...@gmail.com wrote:
I'm not sure if we need that sort of syntax and opinionated approach: I like
Benjamin's approach better, and it is also simpler and still very easy to use
even in our context (doctrine).
For example, this alternative
On 4 November 2014 17:07, Jakub Zelenka bu...@php.net wrote:
On Tue, Nov 4, 2014 at 2:57 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Nov 4, 2014 at 4:13 AM, Juan Basso jrba...@gmail.com wrote:
Hi,
I opened a pull request[1] in order to solve the bug 50224[2] and it
ended
2014-11-05 17:02 GMT+03:00 Marco Pivetta ocram...@gmail.com:
For example, this alternative approach perfectly fits the current
doctrine/annotations use-case:
use Doctrine\ORM\Mapping\Entity;
use Doctrine\ORM\Mapping\Table;
use Doctrine\ORM\Mapping\Id;
use
I think keeping this just like an array definition in a property would make
this both simple and flexible.
You can even improve on Marcos example with a class having constants:
namespace Doctrine\ORM\Mapping\Annotations;
class ORM
{
const ENTITY = 'Doctrine\ORM\Mapping\Annotations\Entity';
On 11/4/14, 3:31 PM, Stas Malyshev wrote:
Hi!
Primarily, I do not see docblocks as the right place to store class'
metadata information. Metadata != Comments.
I personally regard this as a kind of superstition. There's nothing
wrong with extending what can be in comments. In fact,
I also prefer to use different flags if we enable by default. So if this
behavior is enabled by default in 7.0 the JSON_PRESERVE_FRACTIONAL_PART is
deprecated and a new flag is created to disable it.
In resume of this thread, seems everyone if fine in having the flag
On Wed, Nov 5, 2014 at 2:33 PM, Chris Wright c...@daverandom.com wrote:
I'm afraid I have to disagree here, I don't like the idea of changing this
behaviour without making it controllable, and your logic is also slightly
flawed - it's not that you'd have to do an ~ to disable, it's that it
On 5 Nov 2014, at 16:23, Juan Basso jrba...@gmail.com wrote:
Andrea, I see your concerns about the bigint changes, but I am not sure if
they are related. The PR just affect the encoding, not the decoding part.
Yes, I realise that.
So if some Python system encodes a JSON using the decimal
On Wed, Nov 5, 2014 at 4:23 PM, Juan Basso jrba...@gmail.com wrote:
I also prefer to use different flags if we enable by default. So if this
behavior is enabled by default in 7.0 the JSON_PRESERVE_FRACTIONAL_PART
is deprecated and a new flag is created to disable it.
In resume of this
On Wed, Nov 5, 2014 at 2:33 PM, Chris Wright c...@daverandom.com wrote
I'm afraid I have to disagree here, I don't like the idea of changing this
behaviour without making it controllable
If we make it default, then we could of course add a new constants that
would allow the old behaviour.
On 5 Nov 2014, at 16:45, Jakub Zelenka bu...@php.net wrote:
On Wed, Nov 5, 2014 at 2:33 PM, Chris Wright c...@daverandom.com wrote
I'm afraid I have to disagree here, I don't like the idea of changing this
behaviour without making it controllable
If we make it default, then we
On 11/5/14, 9:15 AM, Alexander Lisachenko wrote:
2014-11-05 17:02 GMT+03:00 Marco Pivetta ocram...@gmail.com:
For example, this alternative approach perfectly fits the current
doctrine/annotations use-case:
use Doctrine\ORM\Mapping\Entity;
use Doctrine\ORM\Mapping\Table;
use
On 5 November 2014 16:45, Jakub Zelenka bu...@php.net wrote:
On Wed, Nov 5, 2014 at 2:33 PM, Chris Wright c...@daverandom.com wrote
I'm afraid I have to disagree here, I don't like the idea of changing
this behaviour without making it controllable
If we make it default, then we could of
On Wed, Nov 5, 2014 at 5:34 PM, Jakub Zelenka bu...@php.net wrote:
On Wed, Nov 5, 2014 at 4:23 PM, Juan Basso jrba...@gmail.com wrote:
I also prefer to use different flags if we enable by default. So if this
behavior is enabled by default in 7.0 the JSON_PRESERVE_FRACTIONAL_PART
is
On 5 November 2014 11:43, Chris Wright c...@daverandom.com wrote:
On 5 November 2014 11:22, Leigh lei...@gmail.com wrote:
On 4 November 2014 18:14, Rowan Collins rowan.coll...@gmail.com wrote:
If anything, I think I would expect the keys of splatted arrays to be
discarded, since it seems
On Wed, Nov 5, 2014 at 4:52 PM, Chris Wright c...@daverandom.com wrote:
I'm sorry, but I don't understand why it would need to be deprecated. For
me making it the default behaviour would mean changing the default value
of the $flags argument to JSON_PRESERVE_FACTIONAL_PART. The flag would
On 5 Nov 2014, at 17:01, Ferenc Kovacs tyr...@gmail.com wrote:
2, there is a chance that there are some exotic apps/systems which are
already depending on the fact that php will/was used to send out 1 instead
of 1.0, and while we can break BC in a major release, the migration for
those
On 5 November 2014 17:21, Jakub Zelenka bu...@php.net wrote:
On Wed, Nov 5, 2014 at 4:52 PM, Chris Wright c...@daverandom.com wrote:
I'm sorry, but I don't understand why it would need to be deprecated. For
me making it the default behaviour would mean changing the default value
of the
On 5 Nov 2014, at 12:51, Lester Caine les...@lsces.co.uk wrote:
On 05/11/14 11:29, Andrea Faulds wrote:
Perhaps something does already exist that I'm missing?
https://github.com/asmblah/uniter
There's also http://phpjs.hertzen.com and
https://code.google.com/p/php-to-js/ and some
https://bugs.php.net/bug.php?id=68331
I was hoping the submitter (or one of their coworkers who commented on
it) would reach out to the list themselves to get more information
since I don't know the whole situation. I did ask them to...
Sorry, I had an email written up to send out to the
On Wed, Nov 5, 2014 at 6:24 PM, Andrea Faulds a...@ajf.me wrote:
On 5 Nov 2014, at 17:01, Ferenc Kovacs tyr...@gmail.com wrote:
2, there is a chance that there are some exotic apps/systems which are
already depending on the fact that php will/was used to send out 1
instead
of 1.0, and
On Wed, Nov 5, 2014 at 6:49 PM, Mark Caudill mark.caud...@grooveshark.com
wrote:
https://bugs.php.net/bug.php?id=68331
I was hoping the submitter (or one of their coworkers who commented on
it) would reach out to the list themselves to get more information
since I don't know the whole
Hi list,
I'd like to introduce thresholds of backwards compatibility breaks, i.e.
maximum numbers of allowed BC breaks per version.
Lester's mail from a couple days ago had me thinking about the BC breaks
that occur now and then in all the RFCs or all the mails I see these days.
Now, take what I
2014.11.05. 21:21 ezt írta (Florian Margaine flor...@margaine.com):
Hi list,
I'd like to introduce thresholds of backwards compatibility breaks, i.e.
maximum numbers of allowed BC breaks per version.
Lester's mail from a couple days ago had me thinking about the BC breaks
that occur now
Hi!
Do we always load the class in the hint? We could perhaps only do it
for inheritance checks?
No, classes are not loaded for type checks, since it would be pointless
- if the class is not loaded, you could not have a value of that type,
so if the class is not present, the answer is no.
--
On 5 Nov 2014, at 21:05, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Do we always load the class in the hint? We could perhaps only do it
for inheritance checks?
No, classes are not loaded for type checks, since it would be pointless
- if the class is not loaded, you could not
Hi all,
On Wed, Nov 5, 2014 at 10:54 AM, Damian Wadley p...@requinix.net wrote:
Apparently this caused
problems for some people as they made 68331 a few days ago.
Just a quick note for this. The user would like to access session
data(session handler)
regardless of data modification. I
On Thu, Nov 6, 2014 at 12:05 AM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
Do we always load the class in the hint? We could perhaps only do it
for inheritance checks?
No, classes are not loaded for type checks, since it would be pointless
- if the class is not loaded, you could
Hi,
According to the discussion on GitHub, I've made some changes on this PR:
- Added a new FILTER_VALIDATE_DOMAIN filter validating domain names
- Added a FILTER_FLAG_HOSTNAME flag to allow checking hostnames (_ are
forbidden in hostname but not in domains)
- Changed FILTER_VALIDATE_URL to use
On 5 Nov 2014, at 21:43, Dmitry Stogov dmi...@zend.com wrote:
On Thu, Nov 6, 2014 at 12:05 AM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
Do we always load the class in the hint? We could perhaps only do it
for inheritance checks?
No, classes are not loaded for type checks,
Hi!
No, classes are not loaded for type checks, since it would be pointless
- if the class is not loaded, you could not have a value of that type,
so if the class is not present, the answer is no.
It's not true anymore, with this proposal.
This is not good. The base premise
I would also prefer to use the same return type hinting compatibility rules
as for argument type-hinting.
May be it's less smart, but more practical.
http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29
Thanks. Dmitry.
On Thu, Nov 6, 2014 at 1:15 AM, Stas Malyshev
I'm not keen on the idea of adding more superglobals to PHP, although I
certainly understand the grave concern of breaking people's code and as
such I've chosen not to pursue the idea of removing superglobals.
I will, however, revisit the idea of exposing the underlying SAPI
callbacks, for
Me as a user and developer PHP RESTful, enough auto filling the global
variable.
Make an abstract variable names (_BODY or _FORM), and filled with the value
in all the HTTP methods.
Perhaps it makes sense to do lazy loading of data in these variables, it is
simply done through an ArrayAccess
2014-11-04 20:48 GMT+01:00 Dmitry Stogov dmi...@zend.com:
I agree with Nikita.
Adding an extra argument for one particular security related case looks
weird.
Same opinion here.
Unfortunately, I can't propose something more robust instead, but I
have the feeling that this RFC tries to solve
Hi all,
On Wed, Nov 5, 2014 at 9:52 PM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
thanks for the report.
first let me clarify a couple of things:
1, neither of https://wiki.php.net/rfc/session-lock-ini or
https://wiki.php.net/rfc/session-read_only-lazy_write made into 5.6 in their
Hi,
On Wed, Nov 5, 2014 at 11:30 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
BTW, anyone know the reason why the user need to call
session_write_close()/session_commit()
unconditionally? Accounting, perhaps?
Releasing locks is one example. In userland implementations though, it
could be all
Hi,
On Wed, Nov 5, 2014 at 11:57 PM, Kévin Dunglas dung...@gmail.com wrote:
- Added a new FILTER_VALIDATE_DOMAIN filter validating domain names
- Added a FILTER_FLAG_HOSTNAME flag to allow checking hostnames (_ are
forbidden in hostname but not in domains)
This doesn't make any sense. A
On 5 Nov 2014, at 22:15, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
No, classes are not loaded for type checks, since it would be pointless
- if the class is not loaded, you could not have a value of that type,
so if the class is not present, the answer is no.
It's not
On 5 Nov 2014, at 22:29, Sherif Ramadan theanomaly...@gmail.com wrote:
From all the people I've spoken with that have a problem with handling PUT
requests in PHP, it seems that they'd rather have PHP populate
$_FILES/$_POST automatically in this case. Which would be relatively easy
to do
On 6 Nov 2014, at 00:26, Andrea Faulds a...@ajf.me wrote:
Also, it is kind of weird that arguments require exact match but return
types do not. Not that we care for consistency anymore…
Yeah, we should probably have arguments be contravariant or covariant.
I was going to argue that
On Wed, Nov 5, 2014 at 7:31 PM, Andrea Faulds a...@ajf.me wrote:
On 5 Nov 2014, at 22:29, Sherif Ramadan theanomaly...@gmail.com wrote:
From all the people I've spoken with that have a problem with handling
PUT
requests in PHP, it seems that they'd rather have PHP populate
On 6 Nov 2014, at 01:29, Sherif Ramadan theanomaly...@gmail.com wrote:
So you're actually describing two semi-different problems here. One is that
PHP doesn't actually inform you of the HTTP request VERB strictly through the
naming of the super global variables $_POST and $_GET. However,
Hi,
On Thu, Nov 6, 2014 at 3:20 AM, Florian Margaine flor...@margaine.com wrote:
Thoughts? Am I thinking too much? Is this idea unfeasible? Is it a good
idea?
Have you missed:
https://wiki.php.net/rfc/releaseprocess
?
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP
Hi Andrey,
On Thu, Nov 6, 2014 at 8:23 AM, Andrey Andreev n...@devilix.net wrote:
Short-term fix for 5.6 is obviously to revert the commit. I was vocal
mostly because of principle at the time, but this issue is an example
why.
Did you? I don't think so.
The reason that I didn't provide
On 5 Nov 2014, at 20:34, Ferenc Kovacs tyr...@gmail.com wrote:
Regardless of those, I think it would be worse from the users POV than our
current policy where we target no BC breaks in minor/micro versions.
The only exception should be security concerns (see the unserialize changes
in 5.6
On Nov 6, 2014 11:46 AM, Andrea Faulds a...@ajf.me wrote:
On 5 Nov 2014, at 20:34, Ferenc Kovacs tyr...@gmail.com wrote:
Regardless of those, I think it would be worse from the users POV than
our
current policy where we target no BC breaks in minor/micro versions.
The only exception
To demonstrate the value of covariance and why `static` alone is not
sufficient, here is a small example:
interface Enumerable extends \IteratorAggregate {
function getIterator(): Enumerator;
}
class Vector implements Enumerable, \ArrayAccess, \Countable {
function getIterator():
HI all,
On Thu, Nov 6, 2014 at 6:30 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Wed, Nov 5, 2014 at 10:54 AM, Damian Wadley p...@requinix.net wrote:
Apparently this caused
problems for some people as they made 68331 a few days ago.
Just a quick note for this. The user would like to
On Wed, Nov 5, 2014 at 8:38 PM, Andrea Faulds a...@ajf.me wrote:
On 6 Nov 2014, at 01:29, Sherif Ramadan theanomaly...@gmail.com wrote:
So you're actually describing two semi-different problems here. One is
that PHP doesn't actually inform you of the HTTP request VERB strictly
through
On 6 Nov 2014, at 02:00, Pierre Joye pierre@gmail.com wrote:
We have minor BC breaks (new errors. Slight behavior changes due to bug
fixes).
But globally no, it makes end users work harder for migration, even worst for
distros.
See Debian f.e., they boost the adoption speed now,
On Nov 5, 2014, at 9:23 PM, Sherif Ramadan theanomaly...@gmail.com wrote:
On Wed, Nov 5, 2014 at 8:38 PM, Andrea Faulds a...@ajf.me wrote:
On 6 Nov 2014, at 01:29, Sherif Ramadan theanomaly...@gmail.com wrote:
So you're actually describing two semi-different problems here. One is
After the comments I see about deprecating the constant. Makes completely
sense to keep it. Thanks for the clarification.
I like the idea to have it enabled by default on 7.0, but since it is not a
major issue, probably keeping it as optional would makes more sense and
doesn't introduce another
On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch willfi...@php.net wrote:
Easy - you have no idea what the input type is from PUT without checking
the incoming type. With POST, you know exactly what it is. PUT input code
be JSON, multipart mime, a file or a whatever the dev wants.
That's not
For the umpteenth time, *in what situation must you PUT multipart/form-data or
multipart/x-www-form-urlencoded only to treat it, semantically, as a POST*?
Which UA cannot send a POST? It's like we're completely upside down on this
thread.
If you're PUTing such POSTful content-types for any
On Wed, Nov 5, 2014 at 10:03 PM, Sanford Whiteman figureone...@gmail.com
wrote:
For the umpteenth time, *in what situation must you PUT
multipart/form-data or multipart/x-www-form-urlencoded only to treat it,
semantically, as a POST*? Which UA cannot send a POST? It's like we're
completely
On Nov 5, 2014, at 10:00 PM, Sherif Ramadan theanomaly...@gmail.com wrote:
On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch willfi...@php.net wrote:
Easy - you have no idea what the input type is from PUT without checking the
incoming type. With POST, you know exactly what it is. PUT
On Wed, Nov 5, 2014 at 10:53 PM, Will Fitch willfi...@php.net wrote:
On Nov 5, 2014, at 10:00 PM, Sherif Ramadan theanomaly...@gmail.com
wrote:
On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch willfi...@php.net wrote:
Easy - you have no idea what the input type is from PUT without
Hi Damian,
On Wed, Nov 5, 2014 at 10:54 AM, Damian Wadley p...@requinix.net wrote:
https://bugs.php.net/bug.php?id=68331
I've reverted incomplete patch for the RFC.
Since the RFC patch
https://github.com/yohgaki/php-src/compare/PHP-5.6-rfc-session-lock
was not merged yet, it has to be
Hi all,
The RFC https://wiki.php.net/rfc/session-lock-ini was accepted and the
patch for this was ready to merge, but it wasn't merged to 5.6 by mistake.
The patch is this.
https://github.com/yohgaki/php-src/compare/PHP-5.6-rfc-session-lock
(It's been a while and it has to be updated for current
Hi Andrey,
Sorry but I think you're wrong. Domain != hostname. Underscore are allowed
in domains (RFC 2181) but not in hostnames (RFC 1123 and next). To quote
Wikipedia:
While a hostname may not contain other characters, such as the underscore
character (_), other DNS names may contain the
2014.11.06. 7:10 ezt írta (Yasuo Ohgaki yohg...@ohgaki.net):
Hi all,
The RFC https://wiki.php.net/rfc/session-lock-ini was accepted and the
patch for this was ready to merge, but it wasn't merged to 5.6 by mistake.
The patch is this.
2014.11.06. 6:02 ezt írta (Yasuo Ohgaki yohg...@ohgaki.net):
Hi Damian,
On Wed, Nov 5, 2014 at 10:54 AM, Damian Wadley p...@requinix.net wrote:
https://bugs.php.net/bug.php?id=68331
I've reverted incomplete patch for the RFC.
Thanks!
Since the RFC patch
2014.11.06. 2:46 ezt írta (Andrea Faulds a...@ajf.me):
On 5 Nov 2014, at 20:34, Ferenc Kovacs tyr...@gmail.com wrote:
Regardless of those, I think it would be worse from the users POV than
our
current policy where we target no BC breaks in minor/micro versions.
The only exception
Hi Ferenc,
On Thu, Nov 6, 2014 at 3:28 PM, Ferenc Kovacs tyr...@gmail.com wrote:
Ps: and dont forget/ignore that originally only the read only/lazy write
parts were accepted, the other two proposals did not.
I think the branch has only read only and lazy write parts. I'll double
check.
The
Good morning, internals!
I would like to present to you an idea that I have for a syntax improvement
for PHP.
The basic idea is to allow arbitrary expressions when using the instanceof
operator. Currently, the second operand can only be a constant reference or
a string:
$foo instanceof
Oh, and thanks to @SaraMG for pointing me to the write direction on writing
an e-mail to the internals :)
Daniel Ribeiro
http://danielribeiro.org
On Thu, Nov 6, 2014 at 11:41 AM, Daniel Ribeiro drgom...@gmail.com wrote:
Good morning, internals!
I would like to present to you an idea that I
It's clear, that covariant types are more smart, but not supporting them,
won't prevent access to more specific type properties and methods.
We are not C++ or Java, and we don't need to cast objects to more specific
types.
On the other hand covariance requires all return types to be defined
On 06/11/14 02:27, Andrea Faulds wrote:
We have minor BC breaks (new errors. Slight behavior changes due to bug
fixes).
But globally no, it makes end users work harder for migration, even worst
for distros.
See Debian f.e., they boost the adoption speed now, we finally see some
The HTTP specification doesn't restrict how the request body is encoded
based on the request verb.
I never said it did... please don't put words in my mouth.
As Will notes, you're sidestepping the point, which standards-savvy
people have been driving at for years: the semantic differences (==
On Wed, Nov 5, 2014 at 10:49 PM, Ferenc Kovacs tyr...@gmail.com wrote:
2014.11.06. 2:46 ezt írta (Andrea Faulds a...@ajf.me):
On 5 Nov 2014, at 20:34, Ferenc Kovacs tyr...@gmail.com wrote:
Regardless of those, I think it would be worse from the users POV than
our
current policy
86 matches
Mail list logo
