On 2011-12-31 16:44, Mark Nottingham wrote: > Looks good to me. > ... ...applied with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1498>.
On 2011-12-30 18:51, Julian Reschke wrote: > ... > Indeed; see my tests at > <http://greenbytes.de/tech/tc/httpredirects/#l-fragments> (note that > Safari appears to have funny issues filling the iframes; but navigating > to the linked resource gets you proper results). > ... I just realized that the rule we would need to describe *almost* is the one define in the URI spec (<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.5.2>) as "relative resolution": > -- The URI reference is parsed into the five URI components > -- > (R.scheme, R.authority, R.path, R.query, R.fragment) = parse(R); > > -- A non-strict parser may ignore a scheme in the reference > -- if it is identical to the base URI's scheme. > -- > if ((not strict) and (R.scheme == Base.scheme)) then > undefine(R.scheme); > endif; > > if defined(R.scheme) then > T.scheme = R.scheme; > T.authority = R.authority; > T.path = remove_dot_segments(R.path); > T.query = R.query; > else(Continue reading)
...
"Almost", because it doesn't use Base.fragment when R.frament is undefined.
a) Should we try describe the algorithm based on RFC 3986 ("do relative resolution as defined by ..., then,
if the result doesn't have a fragment, add the one from the Base URI")?
b) Is this potentially an erratum for RFC 3986?
a) sounds good.
b) I'd call it an "update" rather than an erratum.
On 4/01/2012 3:43 a.m., Julian Reschke wrote:
>
> "Almost", because it doesn't use Base.fragment when R.frament is
> undefined.
>
> a) Should we try describe the algorithm based on RFC 3986 ("do
> relative resolution as defined by ..., then, if the result doesn't
> have a fragment, add the one from the Base URI")?
+1 on this.
>
> b) Is this potentially an erratum for RFC 3986?
>
um.
AYJ
On Wed, Jan 04, 2012 at 06:12:06PM +1300, Amos Jeffries wrote:
> On 4/01/2012 3:43 a.m., Julian Reschke wrote:
> >
> >"Almost", because it doesn't use Base.fragment when R.frament is
> >undefined.
> >
> >a) Should we try describe the algorithm based on RFC 3986 ("do
> >relative resolution as defined by ..., then, if the result doesn't
> >have a fragment, add the one from the Base URI")?
>
> +1 on this.
+1 too.
Willy
Hi there, we just published the -18 drafts of Part 1 through 7 (plus a new version of draft-ietf-httpbis-method-registrations) which reflect the progress we made since the Taipei meeting (where the WG did not meet). Overviews are in the appendices: <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-18.html#changes.since.17> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#changes.since.17> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-18.html#changes.since.17> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p4-conditional-18.html#changes.since.17> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-18.html#changes.since.17> (no changes) <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p6-cache-18.html#changes.since.17> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-18.html#changes.since.17> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-method-registrations-07.html#changes.since.06> (no changes) Diffs: <http://tools.ietf.org/wg/httpbis/draft-ietf-httpbis-p1-messaging/draft-ietf-httpbis-p1-messaging-18-from-17.diff.html>(Continue reading)
Hello Julian, others, On 2012/01/03 23:43, Julian Reschke wrote: > On 2011-12-30 18:51, Julian Reschke wrote: >> ... >> Indeed; see my tests at >> <http://greenbytes.de/tech/tc/httpredirects/#l-fragments> (note that >> Safari appears to have funny issues filling the iframes; but navigating >> to the linked resource gets you proper results). >> ... > > I just realized that the rule we would need to describe *almost* is the > one define in the URI spec > (<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.5.2>) as > "relative resolution": > "Almost", because it doesn't use Base.fragment when R.frament is undefined. > > a) Should we try describe the algorithm based on RFC 3986 ("do relative > resolution as defined by ..., then, if the result doesn't have a > fragment, add the one from the Base URI")? I'm not at all sure that this description is correct. It would mean that I can have something like: Request URI: http://1.example.org/path1/file1.ext Redirect URI: http://2.example.org#frag2 and the result would be: http://2.example.org/path1/file1.ext#frag2(Continue reading)
On 2012-01-04 11:27, "Martin J. Dürst" wrote: > Hello Julian, others, > > On 2012/01/03 23:43, Julian Reschke wrote: >> On 2011-12-30 18:51, Julian Reschke wrote: >>> ... >>> Indeed; see my tests at >>> <http://greenbytes.de/tech/tc/httpredirects/#l-fragments> (note that >>> Safari appears to have funny issues filling the iframes; but navigating >>> to the linked resource gets you proper results). >>> ... >> >> I just realized that the rule we would need to describe *almost* is the >> one define in the URI spec >> (<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.5.2>) as >> "relative resolution": > >> "Almost", because it doesn't use Base.fragment when R.frament is >> undefined. >> >> a) Should we try describe the algorithm based on RFC 3986 ("do relative >> resolution as defined by ..., then, if the result doesn't have a >> fragment, add the one from the Base URI")? > > I'm not at all sure that this description is correct. It would mean that > I can have something like: > Request URI: http://1.example.org/path1/file1.ext > Redirect URI: http://2.example.org#frag2 > > and the result would be:(Continue reading)
Here is a proposal to clarify a few things to help mitigating the
overlapping range DoS issue:
1/ split section 4 in Combining Range in Caches (the actual content)
and add a specific section about combining ranges in responses.
(with a link to security considerations, and link back from security
section to this newly created section.
2/ Responses to single and multiple range requests / Combining Ranges in a
response.
Add:
<<
Servers have liability to combine requested ranges when those ranges
are ovelapping.
>>
[Move this part of 5.2 here]
<<
When an HTTP message includes the content of a single range (for
example, a response to a request for a single range, or to a request
for a set of ranges that overlap without any holes), this content is
transmitted with a Content-Range header field, and a Content-Length
header field showing the number of bytes actually transferred. For
example,
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
(Continue reading)
(FYI) - adds an example using HTML meta/ <at> http-equiv=refresh as fallback - documents current implementations (Chrome: feature requested, Firefox: feature requested and patch provided, Safari: no change required) -------- Original Message -------- Subject: I-D Action: draft-reschke-http-status-308-01.txt Date: Wed, 04 Jan 2012 06:40:28 -0800 From: internet-drafts@... Reply-To: internet-drafts@... To: i-d-announce@... A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect) Author(s) : Julian F. Reschke Filename : draft-reschke-http-status-308-01.txt Pages : 7 Date : 2012-01-04 This document specifies the additional HyperText Transfer Protocol (HTTP) Status Codes 308 (Permanent Redirect). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-reschke-http-status-308-01.txt(Continue reading)
RSS Feed308 | |
|---|---|
546 | |
240 | |
650 | |
495 | |
69 | |
157 | |
271 | |
95 | |
310 | |
897 | |
362 | |
77 | |
365 | |
427 | |
317 | |
304 | |
317 | |
105 | |
144 | |
71 | |
128 | |
313 | |
210 | |
153 | |
121 | |
113 | |
85 | |
75 | |
172 | |
187 | |
309 | |
136 | |
116 | |
144 | |
101 | |
160 | |
87 | |
135 | |
67 | |
78 | |
86 | |
90 | |
169 | |
193 | |
248 | |
438 | |
405 | |
189 | |
232 | |
84 | |
70 | |
162 | |
181 | |
136 | |
115 | |
118 | |
187 | |
209 | |
214 | |
171 | |
260 | |
357 | |
241 | |
165 | |
84 | |
228 | |
97 |
