It buys us also the ability to efficiently decipher the method. Currently we have to convert the string method name to an enum anyway. Why not just start out that way. All the byte savings add up. I think we should consider all the parts of the request line incl URI parts to be simply fields in the request, and be able to only send new values when they change. Default values could be used for various parts as well such as scheme and method. You never know how significant 2 or 3 bytes may be. It could be the difference between needing to split the buffer over more than one packet or not. Sent from my iPad On 2/02/2013, at 10:10, James M Snell <jasnell@gmail.com> wrote: > What does this buy us? Two or three bytes typically? Not worth it. Just send the method name. > > method just isn't a high priority for optimization. > > On Feb 1, 2013 12:33 PM, "Adrien de Croy" <adrien@qbik.com> wrote: >> Not really. >> >> Just reserve a number to indicate the method name is following in text >> >> Or reserve a range for private use >> >> Could even largely avoid sending method at all. If it were treated like a field, default to GET you would only need to send if it changed >> >> >> Sent from my iPad >> >> On 2/02/2013, at 9:28, Julian Reschke <julian.reschke@gmx.de> wrote: >> >> > On 2013-02-01 21:17, Adrien de Croy wrote: >> >> We see ftp:// all the time >> >> >> >> As for using a character or 2 for the method. Why? What is wrong with numbers? >> >> >> >> 1 = GET >> >> 2 = HEAD >> >> 3 = POST >> >> etc. >> >> ... >> > >> > Experimenting with new method names becomes really really hard. >> > >> > Best regards, Julian >>
Received on Friday, 1 February 2013 23:54:04 UTC