On 6/6/11, Boris Zbarsky wrote:
> My point was that there should be _a_ standardized way that sites can
> use to get consistent behavior across browsers. Content-Disposition
> headers see like that way to me.
>
More importantly there should be an implementation defined convention
so users get con
On Mon, Jun 6, 2011 at 6:59 PM, Dennis Joachimsthaler wrote:
> Yes, I was trying to refer to the verbosity. There's no html attributes
> with dashes in them as far as I know, except for "data-", which are user-
> defined. This would kind of break the convention a little. I could think
> about havi
Am 03.06.2011, 15:16 Uhr, schrieb Eduard Pascual :
On Fri, Jun 3, 2011 at 2:23 PM, Dennis Joachimsthaler
wrote:
This grants the ability for any content provider to use an explicit
"Content-Disposition: inline" HTTP header to effectively block
"download links" from arbitrary sources.
True.
On 2011-06-03 17:46, Bjartur Thorlacius wrote:
...
I strongly disagree. I think browsers that use the Content-Disposition
filename for "attachment" but not "inline" are just buggy and should be
fixed.
FWIW MSIE9 seems to honor the filename hint with inline (contrary to
the test results mentio
On 6/5/11 3:53 PM, Bjartur Thorlacius wrote:
On 6/5/11, Boris Zbarsky wrote:
Why need they be? This isn't Bittorrent.
I think you completely misunderstood my mail... the point is that
browses do NOT all use the last non-empty path component; some try to
guess a filename based on the query par
On 6/5/11, Boris Zbarsky wrote:
>> Why need they be? This isn't Bittorrent.
> I think you completely misunderstood my mail... the point is that
> browses do NOT all use the last non-empty path component; some try to
> guess a filename based on the query params, in various ways.
No, I understood -
On 6/3/11 2:58 PM, Bjartur Thorlacius wrote:
On 6/3/11, Boris Zbarsky wrote:
On 6/3/11 11:46 AM, Bjartur Thorlacius wrote:
Note that some browsers will do weird parsing of the query params to
attempt to extract a "useful filename". That seems strictly worse than
just using Content-Disposition
On Fri, 03 Jun 2011 14:24:21 +0100, Boris Zbarsky wrote:
Think a URI like this:
http://mysite.org/generate_progress_report.php?quarter=Q12010
When saving, it would be good to use something like "Progress report of
Q1 2010" as the filename. But that's not "part of the URI" in any sense.
On 6/3/11, Boris Zbarsky wrote:
> On 6/3/11 11:46 AM, Bjartur Thorlacius wrote:
>>> Note that some browsers will do weird parsing of the query params to
>>> attempt to extract a "useful filename". That seems strictly worse than
>>> just using Content-Disposition.
>>>
>> That's slightly better tha
On 6/3/11 2:48 PM, Eduard Pascual wrote:
For a typical snippet of client-side form validation, one or two extra
lines of JS can beautify in advance for a GET form.
Why are you assuming there's any client-side validation code involved?
I'm not sure what do you mean by "no one ever sees the act
On Fri, Jun 3, 2011 at 5:24 PM, Boris Zbarsky wrote:
> On 6/3/11 10:39 AM, Eduard Pascual wrote:
>>>
>>> http://mysite.org/generate_progress_report.php?quarter=Q12010
>>
>> Wouldn't that default (in the absence of a Content-disposition) to
>> "generate_progress_report.php" as the filename?
>
> De
On 6/3/11 11:46 AM, Bjartur Thorlacius wrote:
Note that some browsers will do weird parsing of the query params to
attempt to extract a "useful filename". That seems strictly worse than
just using Content-Disposition.
That's slightly better than just using the last non-empty path
component, th
On 6/3/11, Boris Zbarsky wrote:
>http://mysite.org/generate_progress_report.php?quarter=Q12010
>
> When saving, it would be good to use something like "Progress report of
> Q1 2010" as the filename. But that's not "part of the URI" in any sense.
>
So you're suggesting using the title as the f
On 6/3/11 10:39 AM, Eduard Pascual wrote:
http://mysite.org/generate_progress_report.php?quarter=Q12010
Wouldn't that default (in the absence of a Content-disposition) to
"generate_progress_report.php" as the filename?
Depends on the browser. But yes. And that's a crappy filename for the
On Fri, Jun 3, 2011 at 3:24 PM, Boris Zbarsky wrote:
> On 6/3/11 9:16 AM, Eduard Pascual wrote:
>>
>> Ok, I have never even thought about using the "filename" argument with
>> an explicit "inline" disposition. When I am in control of the headers,
>> I find it easier to "fix" the filename with 301/
On 6/3/11 8:09 AM, Nils Dagsson Moskopp wrote:
Eduard Pascual schrieb am Fri, 3 Jun 2011
10:23:25 +0200:
This grants the ability for any content provider to use an explicit
"Content-Disposition: inline" HTTP header to effectively block
"download links" from arbitrary sources.
… thus placing
On 6/3/11 9:16 AM, Eduard Pascual wrote:
Ok, I have never even thought about using the "filename" argument with
an explicit "inline" disposition. When I am in control of the headers,
I find it easier to "fix" the filename with 301/302 redirects
That doesn't work if the data is dynamically gener
On Fri, Jun 3, 2011 at 2:23 PM, Dennis Joachimsthaler wrote:
>> This grants the ability for any content provider to use an explicit
>> "Content-Disposition: inline" HTTP header to effectively block
>> "download links" from arbitrary sources.
>
> True. Is it still so that some browsers ignore the "
On 2011-06-03 14:23, Dennis Joachimsthaler wrote:
Am 03.06.2011, 10:23 Uhr, schrieb Eduard Pascual :
On Thu, Jun 2, 2011 at 10:09 PM, Dennis Joachimsthaler
wrote:
By the way, another point that we have to discuss:
Which tag should a browser favor. The one in HTTP or the other one in
HTML?
On Fri, Jun 3, 2011 at 2:09 PM, Nils Dagsson Moskopp
wrote:
> Eduard Pascual schrieb am Fri, 3 Jun 2011
> 10:23:25 +0200:
>
>> This grants the ability for any content provider to use an explicit
>> "Content-Disposition: inline" HTTP header to effectively block
>> "download links" from arbitrary s
Am 03.06.2011, 10:23 Uhr, schrieb Eduard Pascual :
On Thu, Jun 2, 2011 at 10:09 PM, Dennis Joachimsthaler
wrote:
By the way, another point that we have to discuss:
Which tag should a browser favor. The one in HTTP or the other one in
HTML?
Is that really worth discussing? HTTP >> HTML: who
Eduard Pascual schrieb am Fri, 3 Jun 2011
10:23:25 +0200:
> This grants the ability for any content provider to use an explicit
> "Content-Disposition: inline" HTTP header to effectively block
> "download links" from arbitrary sources.
… thus placing a burden on content providers. If browser mak
On Thu, Jun 2, 2011 at 10:09 PM, Dennis Joachimsthaler wrote:
> By the way, another point that we have to discuss:
>
> Which tag should a browser favor. The one in HTTP or the other one in
> HTML?
Is that really worth discussing? HTTP >> HTML: whomever provides the
file should have the last say a
Am 02.06.2011, 21:58 Uhr, schrieb Glenn Maynard :
On Thu, Jun 2, 2011 at 3:32 PM, Michal Zalewski
wrote:
I don't think the issue raised was about getting people to save files,
though. If you can get someone to click a link, you can already point
them at something that sets the HTTP C-D head
On Thu, Jun 2, 2011 at 3:32 PM, Michal Zalewski wrote:
>> I don't think the issue raised was about getting people to save files,
>> though. If you can get someone to click a link, you can already point
>> them at something that sets the HTTP C-D header.
>
> The origin of a download is one of the
> I don't think the issue raised was about getting people to save files,
> though. If you can get someone to click a link, you can already point
> them at something that sets the HTTP C-D header.
The origin of a download is one of the best / most important
indicators people have right now (which,
I don't think the issue raised was about getting people to save files,
though. If you can get someone to click a link, you can already point
them at something that sets the HTTP C-D header.
As I recall, the concern was about getting people to do this on files
that appear to be from a trusted doma
> On Linux you may have comprehensive mailcap lists in /etc, or better
> yet the filename extension to MIME type mappings used by httpds.
Which still don't necessarily map to the behavior of every single file
manager; some of them come with their own rules (heck, even mc does
that IIRC), some rely
On 5/26/11, Michal Zalewski wrote:
> Keep in mind that the mechanism *is* extremely imperfect. It only
> works for MIME types and extensions recognized by the browser (which
> is a small list). There's a large disconnect between this set, the set
> handled by the OS, and the actual logic used to c
> Browsers should just use the same behaviour when encountering the function
> in a HTML attribute.
Keep in mind that the mechanism *is* extremely imperfect. It only
works for MIME types and extensions recognized by the browser (which
is a small list). There's a large disconnect between this set,
Am 26.05.2011, 22:58 Uhr, schrieb Julian Reschke :
On 2011-05-26 22:54, Dennis Joachimsthaler wrote:
Am 26.05.2011, 22:53 Uhr, schrieb Boris Zbarsky :
Probably no one, to a first approximation, but we were specifically
talking about non-Windows systems. On Windows, as I said, Gecko forces
ext
On 2011-05-26 22:54, Dennis Joachimsthaler wrote:
Am 26.05.2011, 22:53 Uhr, schrieb Boris Zbarsky :
Probably no one, to a first approximation, but we were specifically
talking about non-Windows systems. On Windows, as I said, Gecko forces
extensions to match content types, to avoid this sort of
Am 26.05.2011, 22:53 Uhr, schrieb Boris Zbarsky :
Probably no one, to a first approximation, but we were specifically
talking about non-Windows systems. On Windows, as I said, Gecko forces
extensions to match content types, to avoid this sort of issue in
general.
Yep, yep... If browsers
On 5/26/11 4:40 PM, Dennis Joachimsthaler wrote:
Though I think it still would happen rarely that a pl file gets downloaded.
The problem is getting the user to save a text file you control as a .pl
file.
I mean who on the most popular system, Windows, has a Perl interpreter
installed?
Pro
Am 26.05.2011, 22:33 Uhr, schrieb Boris Zbarsky :
On 5/26/11 3:12 PM, Dennis Joachimsthaler wrote:
Oh I see the problem... Is it the bang? #!/bin/perl #!/bin/python
#!/bin/bash
could very well result in the text file being executed in one of those
interpreters,
right?
Yes, but even worse on s
On 5/26/11 3:12 PM, Dennis Joachimsthaler wrote:
Oh I see the problem... Is it the bang? #!/bin/perl #!/bin/python
#!/bin/bash
could very well result in the text file being executed in one of those
interpreters,
right?
Yes, but even worse on some systems a .pl file will just handed over to
the
Am 26.05.2011, 21:08 Uhr, schrieb Boris Zbarsky :
Yes, that's the one saving grace. "Usually" is key, though.
Usually, damn.
There is little practical difference for the user between running a
binary and running a perl script, and sneaking in a text file with a .pl
extension might well m
On 5/26/11 2:16 PM, Dennis Joachimsthaler wrote:
Wouldn't this be no immediate problem on Linux type OSs? There's usually
no execution bit set on files downloaded.
Yes, that's the one saving grace. "Usually" is key, though.
And practically you can run ALL files as binaries, it looks for the
Hi Boris,
Am 26.05.2011, 20:15 Uhr, schrieb Boris Zbarsky :
On 5/26/11 2:06 PM, Dennis Joachimsthaler wrote:
I believe it forces the extension to match the MIME type; if the type
text/plain the saved filename will be
"Important_Security_Update.exe.txt".
Ah, alright. This is good though.
On 5/26/11 2:06 PM, Dennis Joachimsthaler wrote:
At least in the case of Firefox for that particular case on Windows
thefilename will be sanitized...
So what does Firefox do in this case?
I believe it forces the extension to match the MIME type; if the type
text/plain the saved filename w
Oh hey,
I didn't realize this topic was discussed again one month ago.
I originally even started this ;-).
Note that somewhat counterintuitively, there would be some security
concerns with markup-level content disposition controls (or any JS
equivalent). For example, consider evil.com doing thi
> At least in the case of Firefox for that particular case on Windows the
> filename will be sanitized...
Yes, but Firefox is an exception, not a rule; and even that mechanism
is very imperfect (it relies on explicit mappings that are not
guaranteed to be in sync with other OS components; when dow
On 4/30/11 2:24 PM, Michal Zalewski wrote:
Note that somewhat counterintuitively, there would be some security
concerns with markup-level content disposition controls (or any JS
equivalent). For example, consider evil.com doing this:
At least in the case of Firefox for that particular case on
> So, it's not so much the security issue (the browser's job), but an
> appearance-of-fault issue: the site not wanting to be blamed if the
> browser fails at that job.
Well, the browser does the best it can (i.e., documents the origin of
a download), and the user does the best he can (examines th
On Sat, Apr 30, 2011 at 2:54 PM, Michal Zalewski wrote:
> My concern is a bit more straightforward. To use a practical example:
> just because a social networking site allows nearly arbitrary JPEG
> files to be uploaded and served as profile pictures (Content-Type:
> image/jpeg) does not mean that
> Maybe a bit more contriving could come up with a more plausible example.
My concern is a bit more straightforward. To use a practical example:
just because a social networking site allows nearly arbitrary JPEG
files to be uploaded and served as profile pictures (Content-Type:
image/jpeg) does no
On Sat, Apr 30, 2011 at 2:24 PM, Michal Zalewski wrote:
> Note that somewhat counterintuitively, there would be some security
> concerns with markup-level content disposition controls (or any JS
> equivalent). For example, consider evil.com doing this:
>
> disposition='attachment; filename="Impor
Note that somewhat counterintuitively, there would be some security
concerns with markup-level content disposition controls (or any JS
equivalent). For example, consider evil.com doing this:
Downloading files in general is a very problematic area, because
there's a very fragile transition betwee
On Mon, Apr 11, 2011 at 1:28 PM, Glenn Maynard wrote:
> On Mon, Apr 11, 2011 at 12:48 PM, Eric Uhrhane wrote:
>>
>> Folks did propose making FileSaver do this at TPAC, but we haven't
>> gotten around to hashing out the details yet. The idea was that
>> FileSaver would take a URL instead of a Blo
On Mon, Apr 11, 2011 at 12:48 PM, Eric Uhrhane wrote:
> Folks did propose making FileSaver do this at TPAC, but we haven't
> gotten around to hashing out the details yet. The idea was that
> FileSaver would take a URL instead of a Blob, and thus could also be
> used for downloading arbitrary lin
On Sun, Apr 10, 2011 at 11:49 AM, Glenn Maynard wrote:
> On Sun, Apr 10, 2011 at 1:59 PM, Bjartur Thorlacius
> wrote:
>
>> Right. As an end-user I ask: Does a web developer publishing links to
>> resources have a say as to whether I render aforementioned resource
>> immediately, write it to disk
On Sun, Apr 10, 2011 at 1:59 PM, Bjartur Thorlacius wrote:
> Right. As an end-user I ask: Does a web developer publishing links to
> resources have a say as to whether I render aforementioned resource
> immediately, write it to disk or both?
>
As far as Content-Disposition already allows us to do
On 4/10/11, Glenn Maynard wrote:
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
>
> A big +1 to the proposal in this thread, to allow specifying
> Content-Disposition behavior in anchors. would
> have the effect of adding (or overriding) the header "Content-Disposit
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
A big +1 to the proposal in this thread, to allow specifying
Content-Disposition behavior in anchors. would
have the effect of adding (or overriding) the header "Content-Disposition:
attachment; filename=filename.txt".
On 07.12.2010 18:51, Dennis Joachimsthaler wrote:
Am 07.12.2010, 10:13 Uhr, schrieb Julian Reschke :
It would be great if those scripts could just get fixed.
Do you actually think that would HAPPEN? I think not. Better have people
get
rid of them entirely. Though that wouldn't happen either.
Am 07.12.2010, 10:13 Uhr, schrieb Julian Reschke :
It would be great if those scripts could just get fixed.
Do you actually think that would HAPPEN? I think not. Better have people
get
rid of them entirely. Though that wouldn't happen either.
I'm still all for such a property in . I perso
On 06.08.2010 05:49, Bjartur Thorlacius wrote:
...
IMO there should be a standard metadata wrapper that should be around
virtually all files being passed around the Internet. Downloaders should
register the metadata to xattrs or somesuch and uploaders should collect
said metadata and rewrap it. T
On 02.08.2010 18:56, Tab Atkins Jr. wrote:
2010/8/2 Kornel Lesiński:
Downloads can be "forced" already with Content-Disposition: attachment. It's
just harder to do, and unfortunately that doesn't stop webmasters from trying. Popular
PHP snippets for forcing download are among the most disgusti
On Thu, 26 Aug 2010, Roger Hågensen wrote:
>
> [..] I navigated to the http://wiki.whatwg.org/wiki/RelExtensions where
> I found: "enclosure" described as "the destination of the hyperlink is
> intended to be downloaded and cached" and it's marked as "proposed"
> currently.
> And it links furthe
Am 28.09.2010, 19:22 Uhr, schrieb Ian Hickson :
On Tue, 28 Sep 2010, Dennis Joachimsthaler wrote:
Oh! That's... kind of cool ;-).
Just be careful that no personal mails get in that folder.
Oh don't worry, I have all kinds of checks in place to avoid that!
Heh, alright!
So I just wait fo
On Tue, 28 Sep 2010, Dennis Joachimsthaler wrote:
> >
> > Yeah, that's just got the e-mails that are pending, not the ones that
> > got a reply. It's actually just a copy of my IMAP folders, updated
> > nightly. :-)
>
> Oh! That's... kind of cool ;-).
> Just be careful that no personal mails ge
Am 26.09.2010, 21:43 Uhr, schrieb Ian Hickson :
On Sun, 26 Sep 2010, den...@efjot.de wrote:
>
> That's unnecessary; I guarantee that I will read and reply to every
> e-mail sent to this mailing list that provides new feedback. All
> pending e-mails are tracked here:
>
> http://www.whatwg.org/
On Sun, 26 Sep 2010, den...@efjot.de wrote:
> >
> > That's unnecessary; I guarantee that I will read and reply to every
> > e-mail sent to this mailing list that provides new feedback. All
> > pending e-mails are tracked here:
> >
> > http://www.whatwg.org/issues/
>
> Alright, but I didn't s
This thread has in fact already received an "official" reply:
I am sorry, I didn't recognize you were one of the "managers" here.
I should've read more.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028148.html
That e-mail received a reply that I haven't responded to yet:
On Sun, 26 Sep 2010, Dennis Joachimsthaler wrote:
>
> I'd like to bring this back to attention.
>
> I don't want this to be forgotten before anybody who is "official" has
> said their definitive yes or no about it.
This thread has in fact already received an "official" reply:
http://lists.w
On 26.09.2010 12:39, Dennis Joachimsthaler wrote:
Hello,
I'd like to bring this back to attention.
I don't want this to be forgotten before anybody who is "official"
has said their definitive yes or no about it.
Or how else do new additions find their way into the draft?
Many were positive ab
Hello,
I'd like to bring this back to attention.
I don't want this to be forgotten before anybody who is "official"
has said their definitive yes or no about it.
Or how else do new additions find their way into the draft?
Many were positive about this feature, so I don't want to let this sink
On 2010-08-25 21:09, Ian Hickson wrote:
On Fri, 30 Jul 2010, Dennis Joachimsthaler wrote:
Having a Content-Disposition property on tags which does the same as
the HTTP Header. For example changing the file name of the file to be
downloaded or rather have a image file download rather than it be
On Fri, 30 Jul 2010, Dennis Joachimsthaler wrote:
>
> Having a Content-Disposition property on tags which does the same as
> the HTTP Header. For example changing the file name of the file to be
> downloaded or rather have a image file download rather than it being
> shown in the browser direc
> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w=
> rote:
> > A) Per resource metadata:
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm=
> ediate
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p=
> rovided by e.g. the
> > =C2=A0 =C2=
> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w=
> rote:
> > A) Per resource metadata:
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm=
> ediate
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p=
> rovided by e.g. the
> > =C2=A0 =C2=
> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w=
> rote:
> > A) Per resource metadata:
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm=
> ediate
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p=
> rovided by e.g. the
> > =C2=A0 =C2=
> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w=
> rote:
> > A) Per resource metadata:
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm=
> ediate
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p=
> rovided by e.g. the
> > =C2=A0 =C2=
> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w=
> rote:
> > A) Per resource metadata:
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm=
> ediate
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p=
> rovided by e.g. the
> > =C2=A0 =C2=
> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w=
> rote:
> > A) Per resource metadata:
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm=
> ediate
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p=
> rovided by e.g. the
> > =C2=A0 =C2=
> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w=
> rote:
> > A) Per resource metadata:
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm=
> ediate
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p=
> rovided by e.g. the
> > =C2=A0 =C2=
> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w=
> rote:
> > A) Per resource metadata:
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm=
> ediate
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p=
> rovided by e.g. the
> > =C2=A0 =C2=
On Mon, Aug 2, 2010 at 7:37 PM, Boris Zbarsky wrote:
> On 8/2/10 1:15 PM, Aryeh Gregor wrote:
>>
>> If you don't agree that this use-case is worth adding the feature for,
>> do you think that:
>> 3) Something else?
>
> For the use case your describe, it might just make more sense for browsers
> to
On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius wrote:
> A) Per resource metadata:
> Some resource is inherently insuitable for immediate
> presentation. Metadata regarding this can be provided by e.g. the
> Content-Disposation header of RFC 2076 (MIME).
Not all resources
On Mon, 02 Aug 2010, Aryeh Gregor wrote:
> On Mon, Aug 2, 2010 at 12:21 PM, Michael Kozakewich
> wrote:
> > I see where you're coming from, but we try not to force users to do things.
>
> Let's say you have an image editor, written using canvas and whatnot.
> You want to have similar UI to nativ
Perhaps to avoid the "legacy baggage" it could be a simple attribute
eg.
This would prevent duplicating 'type', and bringing in all the
"knowledge" people seem to not have about how 'content-disposition'
works in headers.
or even an extension of target?
eg.
Then it would be clear that it's o
On 8/2/10 1:15 PM, Aryeh Gregor wrote:
If you don't agree that this use-case is worth adding the feature for,
do you think that:
3) Something else?
For the use case your describe, it might just make more sense for
browsers to support Content-Disposition on data: URIs directly
somehow... Mayb
On Mon, Aug 2, 2010 at 12:21 PM, Michael Kozakewich
wrote:
> People don't often like it when they're forced to do something. If they want
> to download it, they can select "Save Link As..." from their browser.
If the author can predict that the user probably wants to do this
(like because they ju
Am 02.08.2010 18:21 schrieb Michael Kozakewich:
Dennis wrote:
Yes, but that wouldn't help since I want to force downloads regardless
of the browser settings. Maybe it would do if the type was set to
application/octet-stream, since those, by default, always get downloaded.
People don't often li
Kornel Lesiński wrote:
On 2 Aug 2010, at 17:21, Michael Kozakewich wrote:
I agree that it's not good to force users in general. However, this
attribute can be implemented only as a hint for browsers to display
Open/Save dialog. Users wouldn't be forced to download the file, it
would just
Jeremy Keith wrote:
Dennis wrote:
Yes, but that wouldn't help since I want to force downloads regardless
of the browser settings.
Ah, I see. In that case, I fundamentally disagree with what you are
asking for. Final control should be in the hands of the user, not the
author.
Don't we
2010/8/2 Kornel Lesiński :
> Downloads can be "forced" already with Content-Disposition: attachment. It's
> just harder to do, and unfortunately that doesn't stop webmasters from
> trying. Popular PHP snippets for forcing download are among the most
> disgusting cargo-cult code I've ever seen —
On 2 Aug 2010, at 17:21, Michael Kozakewich wrote:
>>> Dennis wrote:
>> Yes, but that wouldn't help since I want to force downloads regardless
>> of the browser settings. Maybe it would do if the type was set to
>> application/octet-stream, since those, by default, always get downloaded.
>
> Peop
On Mon, Aug 2, 2010 at 9:21 AM, Michael Kozakewich
wrote:
>>> Dennis wrote:
>>
>> Yes, but that wouldn't help since I want to force downloads regardless
>> of the browser settings. Maybe it would do if the type was set to
>> application/octet-stream, since those, by default, always get downloaded.
On Mon, 2010-08-02 at 18:09 +0200, Dennis Joachimsthaler wrote:
> Ben Schwarz wrote:
>
> > I'm really not too sure what pre-existing problem this actually solves.
> > Given that a server sets the correct mime-types for a given resource, we
> > know what "type" it is already.
>
> Yes, since we d
Dennis wrote:
> Yes, but that wouldn't help since I want to force downloads regardless
> of the browser settings.
Ah, I see. In that case, I fundamentally disagree with what you are asking for.
Final control should be in the hands of the user, not the author.
--
Jeremy Keith
a d a c t i o
htt
Dennis wrote:
Yes, but that wouldn't help since I want to force downloads regardless
of the browser settings. Maybe it would do if the type was set to
application/octet-stream, since those, by default, always get downloaded.
People don't often like it when they're forced to do something. If the
Ben Schwarz wrote:
I'm really not too sure what pre-existing problem this actually solves.
Given that a server sets the correct mime-types for a given resource, we
know what "type" it is already.
Yes, since we don't want to set MIME-Types. I want to be able to set
what a file actually is. Is
Jeremy Keith wrote:
Dennis wrote:
...
Hang on... isn't the mechanism for this already available via the "type"
attribute?
For example:
Full size image
That wouldn't help in this case...
A browser could offer a preference setting, for example:
"Always download the following types of f
I'm really not too sure what pre-existing problem this actually solves.
Given that a server sets the correct mime-types for a given resource, we
know what "type" it is already.
Setting the Content-disposition on the client side creates an annoying user
experience.
If I want to open a link in a ne
Dennis wrote:
> I have an idea which would be very cool for HTML5.
>
> Having a Content-Disposition property on tags which does the same as
> the HTTP Header.
> For example changing the file name of the file to be downloaded or rather
> have a image
> file download rather than it being shown in t
On 7/30/10 10:59 PM, Roger Hågensen wrote:
On 2010-07-31 04:52, Boris Zbarsky wrote:
When I say the "Save As" UI I mean the one you get currently, which
varies, some browsers only provide a Save As and Cancel, while others
provide Save As with Open and Cancel.
I can't name a single browser t
On 2010-07-31 04:52, Boris Zbarsky wrote:
When I say the "Save As" UI I mean the one you get currently, which
varies, some browsers only provide a Save As and Cancel, while others
provide Save As with Open and Cancel.
I can't name a single browser that provides an "Open" option if you
select
On 7/30/10 10:27 PM, Roger Hågensen wrote:
On 7/30/10 9:57 PM, Roger Hågensen wrote:
This defaults to application/octet-stream
and clicking the link will behave as if the user selected Save As from
UI context menu!
When I say the "Save As" UI I mean the one you get currently, which
varie
On 2010-07-30 20:54, Eduard Pascual wrote:
Let me complement the proposal with a use case:
http://stackoverflow.com/questions/3358209/triggering-a-file-download-without-any-server-request
Now something like that is a bit more tricky, but can't Javascript
actually trigger a proper Save As?
1 - 100 of 106 matches
Mail list logo
