headers
Martin Duerst | 1 Apr 2008 05:54
Picon
Gravatar

Re: PROPOSAL: i74: Encoding for non-ASCII headers


At 05:33 08/04/01, Julian Reschke wrote:
>
>Henrik Nordstrom wrote:
>> mテ・n 2008-03-31 klockan 21:10 +0200 skrev Julian Reschke:
>> 
>>> As far as I remember, this means "encode non-ASCII characters in UTF-8, then percent-escape".
>> In my tests the request-URI is percent-escaped, but Host header sent as
>> raw UTF-8.
>
>OK.
>
>I guess the latter can be considered a bug. Eric?

Here is some background, as far as I understand. In the early days
of IDNs (before there was a WG), Microsoft had a proposal for using
raw UTF-8 for IDNs in the DNS. Some of that got implemented in
their servers and clients, and this is probably a leftover.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@...
Permalink | Reply | 0 comments |
headers
Martin Duerst | 1 Apr 2008 07:15
Picon
Gravatar

Re: PROPOSAL: i74: Encoding for non-ASCII headers


At 03:28 08/04/01, Roy T. Fielding wrote:
>
>On Mar 31, 2008, at 10:51 AM, Henrik Nordstrom wrote:

>> But at least IE6 has optional support for sending URLs using raw  
>> UTF-8,
>> and it do send raw UTF-8 in the Host header in such setups..
>
>Whoa, that will open up a new can of security worms.

Do you mean due to the nature of UTF-8, or due to
implementations that didn't do enough defensive programming?

Some of this has been around for quite a while.
With security, there is no 100%, but the chances are that
potential security holes have already received some
scrutinity.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@...
Permalink | Reply | 0 comments |
headers
Martin Duerst | 1 Apr 2008 09:05
Picon
Gravatar

Re: PROPOSAL: i74: Encoding for non-ASCII headers


At 08:36 08/03/30, Henrik Nordstrom wrote:

>The only iso-8859-1 use that is interop dependent is in authentication I
>think. But there MAY Be some interop charset dependencies in cookies as
>well..

My personal guess would be that cookies as implemented are essentially
bytes-in-bytes-out, i.e. what's sent from the server is sent back
again by the client.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@...
Permalink | Reply | 1 comment |
headers
Henrik Nordstrom | 1 Apr 2008 10:20
Gravatar

Re: PROPOSAL: i74: Encoding for non-ASCII headers


tis 2008-04-01 klockan 16:05 +0900 skrev Martin Duerst:
> At 08:36 08/03/30, Henrik Nordstrom wrote:
> 
> >The only iso-8859-1 use that is interop dependent is in authentication I
> >think. But there MAY Be some interop charset dependencies in cookies as
> >well..
> 
> My personal guess would be that cookies as implemented are essentially
> bytes-in-bytes-out, i.e. what's sent from the server is sent back
> again by the client.

Yes, which is why I said there is likely to be interop issues when the
cookies is accessed by both sides, not when it's simply echoed.

i.e. javascript/flash/whatever accessing/setting/modifying cookies also
used by the server.

But to be honest I kind of suspect such interop issues is already there.
The HTML side (and javascript running in that context) has already had
it's share of I18N support using various encodings natively without
strange encoding/recoding rules, and there most likely is some
implementations not constraining what javascript requests from http to
what http technically allows..

Regards
Henrik
Permalink | Reply | 0 comments |
headers
Julian Reschke | 1 Apr 2008 16:48
Picon
Picon

Re: PROPOSAL: i76 Use Proxy


Ok,

trying to make progress here.

I have checked in the following change with the goal to finally close 
this issue.

<http://tools.ietf.org/wg/httpbis/trac/changeset/235>

New text:

9.3.6.  305 Use Proxy

    The 305 status was defined in a previous version of this
    specification (see Appendix A.2), and is now deprecated.

and:

A.2.  Changes from RFC 2616

    ...

    Deprecate 305 Use Proxy status code, because user agents did not
    implement it.  It used to indicate that the requested resource must
    be accessed through the proxy given by the Location field.  The
    Location field gave the URI of the proxy.  The recipient was expected
    to repeat this single request via the proxy.  (Section 9.3.6)

    ...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Story Henry | 1 Apr 2008 17:47

Sketch of a very simple identification protocol

By thinking about a use case involving Distributed Open Social  
Networks we found the need for a light weight identification system  
such as OpenId, but without the many redirects and better able to work  
with REST web architecture and Linked Data. The main reasons for  
needing such a protocol were laid out on the Semantic Web mailing list  
[1].

I summarized and illustrated a sketch of such a protocol on a recent  
blog post.

http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword

It is very simple, and probably could be further simplified. Some  
people have noted the similarity with HTTPS, and how this could be  
thought of as an extension to that perhaps [2]. In any case I thought  
that with some protocols experts on this list would be able to fill in  
the gaps, suggest improvements or point to specs that already do what  
is needed.

Yours sincerely,

	Henry

[1] http://www.w3.org/mid/37747504-ABB6-4074-8C98-2EB543F80993-34e3GNjADZTR7s880joybQ <at> public.gmane.org
[2] see http://www.w3.org/mid/62649.81.2.120.180.1206622777.squirrel-Uum2ymaEwGoqdlJmJB21zg <at> public.gmane.org
Attachment (smime.p7s): application/pkcs7-signature, 2429 bytes
Permalink | Reply | 8 comments |
headers
Henrik Nordstrom | 1 Apr 2008 22:33
Gravatar

Re: PROPOSAL: i76 Use Proxy


It's fine to me.

Regards
Henrik

tis 2008-04-01 klockan 16:48 +0200 skrev Julian Reschke:
> Ok,
> 
> trying to make progress here.
> 
> I have checked in the following change with the goal to finally close 
> this issue.
> 
> <http://tools.ietf.org/wg/httpbis/trac/changeset/235>
> 
> New text:
> 
> 9.3.6.  305 Use Proxy
> 
>     The 305 status was defined in a previous version of this
>     specification (see Appendix A.2), and is now deprecated.
> 
> and:
> 
> A.2.  Changes from RFC 2616
> 
>     ...
> 
>     Deprecate 305 Use Proxy status code, because user agents did not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lisa Dusseault | 1 Apr 2008 22:38
Favicon

Re: Sketch of a very simple identification protocol


Another idea in the ether these days is much the same thing, but with  
a different focus and nomenclature: it's typically described as doing  
service discovery in a way that doesn't require DNS changes.

How do I as a person, advertise my personal blog, my calendar, my work  
blog at all, let alone as them being related to me?   My calendar is  
probably hosted by my company or at Google, my personal blog at  
LiveJournal, my work blog by some IT team at my company that has  
nothing to do with the email/calendar team.  There's no way I can get  
those service providers to work together or do something that's  
specific to me.  The extensive work on S-NAPTR and DDDS isn't going to  
help because my company won't put a DNS record saying "Lisa's calendar  
is on google under this address".  Nor will anybody else except me.

But since I don't run a DNS server and don't pay GoDaddy to run one  
for me, I'd rather the information about these related resources be in  
an HTTP resource somewhere -- that's a technology I do have access  
to.  We do have a bootstrap problem, but to a certain extent that can  
be solved with well-known naming conventions.  Just like spiders  
recognize "robots.txt" today, there's a good chance that robots or  
other automated agents can recognize a well-known file name for  
information that advertises services.

Lisa

On Apr 1, 2008, at 8:47 AM, Story Henry wrote:

> By thinking about a use case involving Distributed Open Social  
> Networks we found the need for a light weight identification system
(Continue reading)

Permalink | Reply | 4 comments |
headers
Henrik Nordstrom | 1 Apr 2008 23:33
Gravatar

Re: Sketch of a very simple identification protocol


tis 2008-04-01 klockan 17:47 +0200 skrev Story Henry:

> http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword
> 
> It is very simple, and probably could be further simplified. Some  
> people have noted the similarity with HTTPS, and how this could be  
> thought of as an extension to that perhaps [2].

I see more similaries with HTTP Digest authentication than HTTPS..

Actually you would solve some of the problems mentioned like replay
attacks and nonce management if you do things the Digest way with server
nonce, client nonce + server nonce reuse counter.

You cannot shortcut 1+2 unfortunately while keeping RESTful as HTTP does
not allow mixing public and authenticated content on the same URI, and
attempting to do so will mess up the cache model of HTTP. But 1 only
needs to be performed once for the whole duration of the session (which
can be arbitrary long, subject to server controlled constraints).

But I feel this proposal is perhaps trying to layer too much at the same
time. Better to separate identification from authentiation. If you use
pgp for authentication then the identification key in the authentication
should be the pgp identity (which is a pgp key with some name & email
recorded). But it's also worth noting that pgp signatures do embed the
needed information to identify which key has made the signature (but not
it's distribution points).

What this means is supply the foaf identification separately in an
(Continue reading)

Permalink | Reply | 2 comments |
headers
Josh Cohen (MIG | 2 Apr 2008 01:54
Picon
Favicon

RE: PROPOSAL: i76 Use Proxy


I agree on deprecation.

Regarding the question about this feature's purpose...
I must confess that at the time, I was an advocate in the WG of these features.
The use cases from my memory, while never clearly defined, were oriented around perf, load balancing and security.
An application could instruct clients to access it through a proxy in order to have that proxy do various
caching or balancing.

Similarly, for certain network sources (eg mobile), the app could redirect the client to a proxy that could
do something special for a mobile device, or secure the traffic.  "ah, you are coming from ATT mobile, you
must use their outbound proxy which has a secure connection to us"

I suspect there was also interest in client browser configuration for proxy settings given the activity
going on at the time.  Some other related efforts were ICP (proxy mesh routing protocol), CARP ( client side
proxy hashing ) , javascript configuration files, and WPAD (web proxy autodiscovery).

Today, the common solution to that is WPAD + javascript.

-----Original Message-----
From: ietf-http-wg-request@...
[mailto:ietf-http-wg-request@...] On Behalf Of David Morris
Sent: Wednesday, March 26, 2008 10:07 PM
To: ietf-http-wg@...
Cc: HTTP Working Group
Subject: Re: PROPOSAL: i76 Use Proxy

I agree ... deprecate it ... I still don't see a use case as to why
I'd want to specify a single use proxy as a application designer.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane