j4_james

Fair enough. I agree that they haven't moved between pictures 2 and 3. But I thought the point was that they were out of range by then, so there would be no need to go any further. Although I must admit that explanation seems highly unlikely.

> We're currently discussing how to interpret RFC 2616 (http 1.1) for this here: https://github.com/tus/tus-resumable-upload-protocol/issues/...

I've followed up with further comments there.

> If you have a better suggestions than using the Range header that will still allow clients to send multiple file chunks in parallel, I'd be very interested in it!

I don't see a way to support parallel transfers using only existing HTTP headers (without violating the HTTP spec). I would suggest maybe proposing a new header in the HTTPbis WG. For example, something like Available-Ranges that returns a ranges-specifier indicating the set of ranges that are avaiable.

This could possibly be returned as part of a 416 response when attempting to GET a file that isn't entirely available yet. A HEAD request would thus return the same thing.

> It's 100. We haven't specified GET requests yet, but a server could stream an upload in this case until all bytes have been received.

The reason I brought up a GET request is because "the metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request." (section 9.4 of RFC2616)

If you haven't got all 100 bytes yet, your GET request can't return a Content-Length of 100, thus your HEAD request shouldn't be returning 100 either.

I would have thought you would return whatever content you had available (hence the 70 bytes), but if you want to support parallel transfers, then a 416 error response indicating the available ranges might make more sense.

I think some of your responses aren't quite right. For example, in response to the first PUT, you have:

  HTTP/1.1 200 Ok
  Range: bytes=0-99
  Content-Length: 0

But the Range header surely can't be used here, since it's a request header and this is a response. A Content-Range header wouldn't be any more appropriate, since you're not actually returning any content (of any amount). Do you really need this info in the response anyway? The sender knows what they sent, and either it was entirely successful (a 2xx response) or it wasn't.

Also, if you're going to return a zero-length 200 response, you might as well use 204 No Content instead.

Then, when resuming an upload, you send a HEAD that returns the following:

  HTTP/1.1 200 Ok
  Content-Length: 100
  Content-Type: image/jpg
  Content-Disposition: attachment; filename="cat.jpg"'
  Range: bytes=0-69

Again, you can't use the Range request header in a response. And the Content-Length should surely be 70, since that's how much content would be returned if this was a GET request. You could possibly include a Content-Range of 0-69/100 if the server wanted to communicate the expected file size, but I'm not convinced that's necessary and seems something of an abuse of that header.

Finally, the response to the resumed PUT has the same problems as the first PUT response. It should probably just be a 204 No Content response - no Content-Length or Range headers required.

They're definitely moving.

In the first picture, they're standing next to the lamp post near the tree (you can see the branches on the left). Also note the no stopping sign facing inwards.

In the last picture, they've moved further away from the finish line to the next lamp post - you can see the first lamp post and tree in the background. Also note the no stopping sign on the second lamp post is facing the road.

Less obviously, you can see the Slovakia flag, third to the left of the lamp post in the first picture. Harder to make out in the second picture, but it's clearly a white/blue/red tricolor.

I always thought "protocol" was a more appropriate term for such internet-based APIs. SMTP and HTTP are clearly protocols, and even APIs built on top of HTTP are generally referred to as protocols in the standards world. For example WebDAV (RFC4918) and AtomPub (RFC5023) are both considered protocols.

I would have thought this is just because Java forces you to catch most exceptions. It's only the RuntimeException subclasses (which includes NullPointerException) that are unchecked. And a good deal of those are quite obscure. I really wouldn't expect to see many occurrences of FileSystemAlreadyExistsException or MalformedParameterizedTypeException.

There are also the Error classes (including OutOfMemoryError) that wouldn't automatically be caught, but there aren't many likely candidates there either.

I'm not sure exactly what you had in mind, but there is a CSS proposal to support paging in general on any kind of content.

For example if you had a very tall SVG image, you would constrain the height of the block that it was in, and set the overflow-style to paged-y. The browser would then provide some form of control for you to page vertically through the content in that block.

This stuff is currently documented in the GCPM module, but I suspect it will move somewhere else eventually.

http://www.w3.org/TR/css3-gcpm/

Like a lot of people here, this brings back fond memories. For me, the first real experience of disassembling was with DOS games, when you would use a TSR (terminate and stay resident) debugger to hook into a running executable and try and figure out what it was doing. I think at the time I was mostly interested in hacking infinite lives - I was a lousy gamer.

I remember one of the tricks used by apps was to encrypt the code in some way, and rely on the DOS single-step interrupt to execute the decryption process as the code was run, one instruction at a time. The idea was to prevent static disassembly with the encryption while also discouraging run-time analysis (since a debugger would usually overwrite the single-step interrupt that fired off the decrypter).

I actually ended up writing my own TSR debugger that could step through such code by chaining the interrupts. It could also detect many of the self extracting compression formats and jump past the decompression stage on startup so you didn't spend the first 10 minutes trying to step through decompression code. I was quite proud of that app.

Then in the late 90s I moved on to Windows disassembly, when I became somewhat obsessed with uncovering the undocumented APIs in Windows 95. I even had a Geocities website where I used to publish some of my findings. The site is obviously gone now, but it's still mirrored in a few places.

In case anyone is interested, there's a mirror here: http://koti.mbnet.fi/vaultec/files/miscellaneous/undocw95/

Actually, I thought it was interesting how different they were, at least in some respects. If you look at the ratio of pre 4.0 versions vs post 4.0 versions, in the Unity stats it's about 27% vs 72%, but on the Android dashboard it's 45% vs 54%.

Perhaps Unity apps aren't as widely used on older devices and thus the stats are skewed in favour of more recent versions of Android.

Then again, the Android dashboard data is collected from the Google Play Store, so it isn't a perfect representation of all Android users either.

Another way to achieve this effect:

  hr {
    background-image:
      linear-gradient(left,rgba(195,195,195,0),rgba(195,195,195,1),rgba(195,195,195,0)),
      linear-gradient(left,rgba(255,255,255,0),rgba(255,255,255,1),rgba(255,255,255,0));
    background-position:0 0,0 1px;
    background-repeat:no-repeat;
    background-size:100% 1px,100% 3px;
    border:0;
    height:4px;
  }

Fallback is non-existent for browsers that don't support linear gradients, but it has the advantage of automatically working with any background color.

Not a criticism of the original solution - just offering an alternative approach to the problem.

From an article on NPR (http://www.npr.org/2013/01/28/170473476/north-koreas-rhetori...): "The toughest technology in the nuclear world is to shrink a nuclear weapon down to something that is light enough to fit on a warhead and that can detonate at the right place and so forth."

Not only does the Firefox subscription mechanism work with other web clients, it supports desktop clients as well. It doesn't require registration with a centralised server, nor does it require websites to add a button to their page to enable subscription. In fact it's better than this proposal in every possible way.

The real problem was that not many people cared to subscribe to feeds, so it was considered a waste of space to have on the toolbar by default. It's easy enough to add back though...

http://support.mozilla.org/en-US/kb/customize-navigation-but...

In case you're interested, this is the bug report that resulted in the change: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19741

The final editor's response explains the reasoning: "Change removed advice recommending use of h1 elements as the utline algorithm has virtually no implementations and as a result use of h1 elements flattens document outlines for users who actually consume the heading semantics. While use of elements of the appropriate rank for the section's nesting level is backwards compatible"

It's worth mentioning that in HTML 5.1 they are now recommending that you use headings with an appropriate rank. Not that it's wrong to have multiple H1 tags, just not recommended anymore.

Exact wording: Sections may contain headings of any rank, but authors are strongly encouraged to use headings of the appropriate rank for the section's nesting level.

http://www.w3.org/html/wg/drafts/html/master/sections.html#h...