Re: FYI... Binary Optimized Header Encoding for SPDY

The HTTP proxy syntax is an ongoing source for security issues, due to too  
relaxed pattern matching.

GET http://random.com/?facebook.com HTTP/1.1
GET http://facebook.com@random.com/ HTTP/1.1
GET http://facebook.com.random.com/ HTTP/1.1

etc.

/Martin Nilsson


On Fri, 03 Aug 2012 19:04:05 +0200, Zhong Yu <zhong.j.yu@gmail.com> wrote:

> Wait... why should HTTP care about the internal structure of a URI? As
> far as HTTP is concerned, a URI is an opaque string(though
> canonicalization needs to be defined)
>
> The internal structure of a URI is agreed upon by the client app and
> the server app. For example, the common ?n1=v1&n2=v2 form is actually
> defined by the HTML standard; the way n/v's are escaped is also
> defined by HTML. HTTP has no business in it.
>
> http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4.1
>
> Zhong YU
>
>
> On Fri, Aug 3, 2012 at 12:15 AM, Adrien W. de Croy <adrien@qbik.com>  
> wrote:
>>
>> ------ Original Message ------
>> From: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
>> To: "James M Snell" <jasnell@gmail.com>
>> Cc: "Poul-Henning Kamp" <phk@phk.freebsd.dk>;"Mike Belshe"
>> <mike@belshe.com>;"ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
>> Sent: 3/08/2012 4:35:00 p.m.
>> Subject: Re: FYI... Binary Optimized Header Encoding for SPDY
>>>
>>> On 2012/08/03 2:48, James M Snell wrote:
>>>>
>>>> On Thu, Aug 2, 2012 at 1:27 AM, Poul-Henning
>>>> Kamp<phk@phk.freebsd.dk>wrote:
>>>
>>>
>>>>> For instance, could we get rid of the %-encoding of URIs by allowing
>>>>> UTF8 ?
>>>>
>>>>
>>>> It would be possible, for instance, to begin using IRI's directly  
>>>> without
>>>> translating those to URI's first.
>>>
>>>
>>> Great idea. Please note that that will also save a few bytes (but  
>>> that's
>>> definitely not the main reason for doing it).
>>>>
>>>> Doing so, however, does not eliminate the need for %-encoding,
>>>
>>>
>>> Yes, a '#' or '?' in a path segment and similar stuff still have to be
>>> %-encoded.
>>
>>
>> if we're defining a new binary-safe transport for header values,  
>> shouldn't
>> we try to avoid all multiplexing / escaping and parsing of strings?
>>
>> e.g. just put querystring in another "header" instead.  Then anything  
>> can
>> contain '?'
>>
>> same with fragments (#) although I thought these weren't allowed on the
>> wire...
>>
>> In fact the concept of a single string which is a URI could be  
>> deprecated
>> for 2.0 and just be sent as individual fields in a request.
>>
>> gatewaying back to 1.1 would require assembling a URI from the pieces,  
>> but
>> that should be easy.
>> Seems a bit nuts to go binary and leave some parts as overloaded string
>> fields requiring string parsing and escaping.
>>
>> Adrien
>>
>>
>>>
>>>
>>>> and there are a range of possible issues that could make this
>>>> problematic.
>>>
>>>
>>> Could you list up the issues you're thinking about? (I don't want to  
>>> say
>>> there are none, but I can't at the moment come up with something that
>>> wouldn't already be around currently.)
>>> Regards, Martin.
>>
>>
>>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Received on Monday, 6 August 2012 18:53:50 UTC