Re: Increasing precision of Last-Modified header to allow sub-second granularity?

In message <4F286012.6040205@...>, Adrien de Croy writes:

>>>    Last-Modified: Fri, 27 Jan 2012 20:21:10.011483 GMT
>
>the ability to compare against other previous Last-Modified headers.  
>That allows the client to know whether a version supercedes another, 
>rather than having to defer to the server.
>
>I'd be in favour.

Me too.

But there are necessary consequential changes:
	Expires: headers
	Cache-Control: age fields.
	Age: header.
Possibly more.

Have anybody tried sending such dates to see how much code it breaks ?

I would fear a lot of both clients and servers would choke on it.

--

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@...         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Re: Informal Last Call for HTTP Preference Header

On 01.02.2012 12:58, Cyrus Daboo wrote:
> Hi James,
>
> --On January 31, 2012 1:28:17 PM -0800 James Snell 
> <jasnell@...> wrote:
>
>> I just posted an update for the HTTP Prefer Header altering the
>> intended status from "Informational" to "Standards Track". No
>> additional changes were made. As I have not received any further
>> technical input on the specification, I am issuing an *Informal* 
>> Last
>> Call for comments before I request that it be kicked up the chain 
>> for
>> review.
>>
>> Mark Nottingham has agreed to serve as the document shepherd for
>> helping to move it forward.
>>
>> Current Draft: http://www.ietf.org/id/draft-snell-http-prefer-11.txt
>
> Can you clarify the meaning of an ETag header returned in the
> response to a PUT with a Prefer:return-representation header. Would
> that ETag refer to the resource whose representation is being
> returned?

If it does not something is badly broken. HTTPbis part 4 section 2.3:
"
2.3. ETag

    The ETag header field provides the current entity-tag for the

Re: Increasing precision of Last-Modified header to allow sub-second granularity?

On Wed, 1 Feb 2012, Amos Jeffries wrote:

> 
> What type of sub-second resolution do you expect to work over a protocol with:
>  * seconds of RTT,
>  * clock skew scaled from whole seconds up to days (a week or so skew between
> two "synced" server behind one LB is not uncommon),
>  * middleware conversion to and from whole seconds,
>  * surrogate generated Date headers

What I would expect is that a server could opt to provide a last-modified 
date with subsecond resolution as an atomic update marker which has
a well specifed ordering for comparison. Book keeping for if-modified
tests would be simpler at the server and clients.

RTT, clock skew, etc. don't matter as the date provided would be 
associated with the resource and the same date used everywhere it is 
stored. Like windows systems today and unix systems with the proper
flags ... yeah I know fractional sections are generally not kept
by the file system.

Middleware issues and surrogates exist for ETag generation as well. 
Frankly, if the surrogate is generating the date header, the precision
increase is a moot point.

And clocks CAN be synced if a server farm is using the extended date.

Of course, it doesn't just plug in. dah! There would be a ripple
effect as others have noted. Probably can't be in HTTP/1.1 but

Re: paramname in draft-reschke-basicauth-enc-04

Seems reasonable. If this is where we're at WRT this draft, it suggests to me it's ready to go...

Cheers,

On 01/02/2012, at 8:18 AM, Julian Reschke wrote:

> On 2012-01-31 08:34, "Martin J. Dürst" wrote:
>> ...
>>>> to the name, `useUTF8` or `use-utf-8="yes" or some such would have been
>>>> clearer).
>>> 
>>> That's another good suggestion; we're not going to allow any other
>>> encoding, so maybe making it a real flag is the best solution. What do
>>> others think?
>> 
>> I'm all in favor.
>> ...
> 
> (tracked at <http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-issues.html#issue.paramname>)
> 
> So
> 
>  WWW-Authenticate: Basic realm="foo", useUTF8
> 
> looks cute, but then there's
> 
>  auth-param     = token BWS "=" BWS ( token / quoted-string )
> 
> (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-18.html#rfc.section.2.1>)
> 

Confusion in preconditions

Re: paramname in draft-reschke-basicauth-enc-04

* Julian Reschke wrote:
>So it needs a value. We could say
>
>   useUTF8="yes"
>
>but then there's always the problem of remembering whether the syntax is 
>"0"/"1", "false"/"true" or "no"/"yes".

Well you need to know what the value should be in any case and since we
only have one valid value this particular problem does not really arise;
one could similarily argue that encoding=utf-8 is confusing because it
suggests other encodings can be used, or that it applies to the WWW-Au-
thenticate header (like the realm parameter if using non-ascii wasn't
deprecated, if I recall correctly). We could meet in the middle and use
something like `use=utf-8` or `options="utf-8"`. But whatever, not a big
issue.
--

-- 
Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Increasing precision of Last-Modified header to allow sub-second granularity?

* Poul-Henning Kamp wrote:
>>>>    Last-Modified: Fri, 27 Jan 2012 20:21:10.011483 GMT

>Have anybody tried sending such dates to see how much code it breaks ?
>
>I would fear a lot of both clients and servers would choke on it.

When writing draft-hoehrmann-date-parsing I looked a bit into that and I
am quite sure this would break very many parsers (I never announced that
draft, nobody ever pointed out the bugs in it, and I do not intend to do
anything with it at this point).
--

-- 
Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: #295: Applying original fragment to "plain" redirected URI (also #43)

On 08/01/2012, at 2:28 AM, Julian Reschke wrote:

> To make this change we could add to:
> 
> "The field value consists of a single URI-reference. When it has the form of a relative reference
([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI
([RFC3986], Section 5)."
> 
> saying
> 
> "... If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the
final value does not, then the original URI's fragment identifier is added to the final value."
> 
> 
> (and also we would kill <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.9.5.p.9>).

Works for me; +1. Some examples wouldn't go astray.

--
Mark Nottingham   http://www.mnot.net/

Re: Confusion in preconditions

On Tue, Jan 31, 2012 at 8:35 PM, Sebastien Lambla <seb@...> wrote:
> I *think* the specification does define partially a behavior when multiple
> conditional headers are present in the scenario leading to a 304, or am I
> misunderstanding the definition?

I would say the spec lists some constraints, that must/should be
satisfied, even in "undefined" scenarios. You may say that's "partial
definition".

    The result of a request having both ... header fields
    is undefined by this specification.

These explicit "undefined" disclaimers sounds out-of-place, given the
general vague nature of the spec. It seems to be a cop-out: "don't
even ask me what if these headers co-exist; I don't want to talk about
it"

One must wonder, the problem of conditionals appears to be very easy.
We can have a simple model and a simple procedure, that succinctly and
precisely defines behaviors in any scenario.

Why does the spec instead "beat around the bush", going very
roundabout ways, only setting some constraints on some scenarios? Are
readers supposed to solve the riddles to learn the underlying model?

Maybe it's because many implementations existed before the spec, and
the spec had to be careful not to brand them as invalid. The spec was
content to merely record generally accepted practice in certain
scenarios, and to forbid generally unexpected/unaccepted behavior in
other scenarios. It did not know a simple model that approximates most
established implementations in all scenarios.

Given the boundary constraints listed in the spec, one may assume many
variants of implementations can be compliant. That may not be the
case. Maybe the constraints are contradictory. Maybe the constraints
are so tight that it allows only a few variants, and it'd be simpler
if the spec directly spells out the few variants instead of the
numerous constraints. It's hard to tell. We need someone who can read
through it without passing out.

Maybe we shouldn't worry too much. Implementations pretty much
anticipate only simple/common scenarios; that's ok because all
participants are similarly simple minded. If we request

    GET / HTTP/1.1
    Host: www.google.com
    If-Match: random-fake-etag

according to the spec the server MUST respond with 412 . But most
servers will (unconsciously) ignore the If-Match and return 200,
because no real world client would send such request in the first
place.

Zhong Yu

Re: Confusion in preconditions

On 01.02.2012 19:11, Zhong Yu wrote:
> On Tue, Jan 31, 2012 at 8:35 PM, Sebastien Lambla wrote:
>> I *think* the specification does define partially a behavior when 
>> multiple
>> conditional headers are present in the scenario leading to a 304, or 
>> am I
>> misunderstanding the definition?
>
> I would say the spec lists some constraints, that must/should be
> satisfied, even in "undefined" scenarios. You may say that's "partial
> definition".
>
>     The result of a request having both ... header fields
>     is undefined by this specification.
>
> These explicit "undefined" disclaimers sounds out-of-place, given the
> general vague nature of the spec. It seems to be a cop-out: "don't
> even ask me what if these headers co-exist; I don't want to talk 
> about
> it"
>
> One must wonder, the problem of conditionals appears to be very easy.
> We can have a simple model and a simple procedure, that succinctly 
> and
> precisely defines behaviors in any scenario.

I am pushing to have the conditionals interpreted as a AND condition 
between all present conditionals.

  if anything needs a special status response -> do that
  if any of the conditions is invalid => 412 status
  if ( (If-Match x) AND (If-None-Match y or z) AND (if-modified-since T) 
AND ... ) => 2xx status
  otherwise 304 status

This *seems* to cover all the use cases and provide a useful consistent 
interpretation for which of the "undefined" cases might be useful or 
senseless as well.

I'm still waiting for someone in this WG with more experience to 
produce a use-case where that rule-of-thumb actually breaks something.

AYJ