{"thread":{"id":"5746","subject":"gitweb: using quotemeta","startedAt":"2006-09-28T21:15:59Z","lastAt":"2006-10-11T09:48:31Z","messageCount":14,"participants":["Luben Tuikov","Junio C Hamano","Jakub Narebski","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"27934","messageId":"20060928211600.97412.qmail@web31808.mail.mud.yahoo.com","threadId":"5746","inReplyTo":null,"subject":"gitweb: using quotemeta","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-09-28T21:15:59Z","receivedAt":"2006-09-28T21:15:59Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"Commit ab41dfbfd4f3f9fedac71550027e9813b11abe3d introduces\nthe use of quotemeta to quote the $filename of the snapshot.\nThe commit message explains:\n\n    Just in case filename contains end of line character.\n\nBut quotemeta quotes any characters not matching /A-Za-z_0-9/.\nWhich means that we get strings like this:\n    \n    linux\\-2\\.6\\.git\\-5c2d97cb31fb77981797fec46230ca005b865799\\.tar\\.gz\n\nIs this the desired behavior?  FWIW, the backslash character\nis not part of of the name, but ended up when the snapshot was written\nto the filesystem.\n\nThanks,\n   Luben\n"},{"id":"27949","messageId":"7vodszshq3.fsf@assigned-by-dhcp.cox.net","threadId":"5746","inReplyTo":"20060928211600.97412.qmail@web31808.mail.mud.yahoo.com","subject":"Re: gitweb: using quotemeta","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-28T23:18:28Z","receivedAt":"2006-09-28T23:18:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov <ltuikov@yahoo.com> writes:\n\n> Commit ab41dfbfd4f3f9fedac71550027e9813b11abe3d introduces\n> the use of quotemeta to quote the $filename of the snapshot.\n> The commit message explains:\n>\n>     Just in case filename contains end of line character.\n>\n> But quotemeta quotes any characters not matching /A-Za-z_0-9/.\n> Which means that we get strings like this:\n>     \n>     linux\\-2\\.6\\.git\\-5c2d97cb31fb77981797fec46230ca005b865799\\.tar\\.gz\n>\n> Is this the desired behavior?  FWIW, the backslash character\n> is not part of of the name, but ended up when the snapshot was written\n> to the filesystem.\n\nOuch, that was a sloppy planning and coding, and sloppier\nreviewing.  Sorry.\n\nWhat is the right quoting there?  Just quoting double-quotes?\n"},{"id":"27950","messageId":"20060928232752.99373.qmail@web31804.mail.mud.yahoo.com","threadId":"5746","inReplyTo":"7vodszshq3.fsf@assigned-by-dhcp.cox.net","subject":"Re: gitweb: using quotemeta","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-09-28T23:27:52Z","receivedAt":"2006-09-28T23:27:52Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano <junkio@cox.net> wrote:\n> \n> Ouch, that was a sloppy planning and coding, and sloppier\n> reviewing.  Sorry.\n> \n> What is the right quoting there?  Just quoting double-quotes?\n\nI'm not sure.  What undesired character could we have in $filename\nof a snapshot?  The commit ab41dfbfd4f message gives this\njustification: \"Just in case filename contains end of line character.\"\n\nIt looks like $filename is constructed by well defined strings:\nbasename($project), $hash and $suffix all of which should be ok.\n\nI'd say we don't need quotemeta for $filename of snapshot.\n\n    Luben\n"},{"id":"28093","messageId":"efpme9$o13$1@sea.gmane.org","threadId":"5746","inReplyTo":"20060928232752.99373.qmail@web31804.mail.mud.yahoo.com","subject":"Re: gitweb: using quotemeta","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-02T00:28:14Z","receivedAt":"2006-10-02T00:28:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Luben Tuikov wrote:\n\n> --- Junio C Hamano <junkio@cox.net> wrote:\n>> \n>> Ouch, that was a sloppy planning and coding, and sloppier\n>> reviewing.  Sorry.\n>> \n>> What is the right quoting there?  Just quoting double-quotes?\n> \n> I'm not sure.  What undesired character could we have in $filename\n> of a snapshot?  The commit ab41dfbfd4f message gives this\n> justification: \"Just in case filename contains end of line character.\"\n> \n> It looks like $filename is constructed by well defined strings:\n> basename($project), $hash and $suffix all of which should be ok.\n> \n> I'd say we don't need quotemeta for $filename of snapshot.\n\nBut we do need quoting for blob_plain and perhaps blobdiff_plain\nviews, although not quotemeta, but perhaps the reverse of unescape,\ni.e. quote '\"', EOLN (end of line) and perhaps also TAB.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28120","messageId":"20061002201256.89409.qmail@web31809.mail.mud.yahoo.com","threadId":"5746","inReplyTo":"efpme9$o13$1@sea.gmane.org","subject":"Re: gitweb: using quotemeta","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-02T20:12:56Z","receivedAt":"2006-10-02T20:12:56Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Jakub Narebski <jnareb@gmail.com> wrote:\n> Luben Tuikov wrote:\n> \n> > --- Junio C Hamano <junkio@cox.net> wrote:\n> >> \n> >> Ouch, that was a sloppy planning and coding, and sloppier\n> >> reviewing.  Sorry.\n> >> \n> >> What is the right quoting there?  Just quoting double-quotes?\n> > \n> > I'm not sure.  What undesired character could we have in $filename\n> > of a snapshot?  The commit ab41dfbfd4f message gives this\n> > justification: \"Just in case filename contains end of line character.\"\n> > \n> > It looks like $filename is constructed by well defined strings:\n> > basename($project), $hash and $suffix all of which should be ok.\n> > \n> > I'd say we don't need quotemeta for $filename of snapshot.\n> \n> But we do need quoting for blob_plain and perhaps blobdiff_plain\n> views, although not quotemeta, but perhaps the reverse of unescape,\n> i.e. quote '\"', EOLN (end of line) and perhaps also TAB.\n\nEscaping for the purposes of HTML _view_ and URL generation is ok,\nbut it is not ok when _saving_ the file with a file name.\n\nA file name is just a string of chars, and I want to _save_ the file\nname as its name is. No changes or interpretations please.  I don't\ncare what the string is, what chars it is made of, etc.\n\nPlease don't interpret file names and their characters when the files\nare _saved_ by the user's browser.\n\nThe file name in my filesystem should be the exact same file name\nas it appears on any other filesystem hosting the same git repo.\n\nI don't want this translation:\nServer FS: linux-2.6.git-5c2d97cb31fb77981797fec46230ca005b865799.tar.gz\nQuotemeta: linux\\-2\\.6\\.git\\-5c2d97cb31fb77981797fec46230ca005b865799\\.tar\\.gz\nUser FS: linux\\-2\\.6\\.git\\-5c2d97cb31fb77981797fec46230ca005b865799\\.tar\\.gz\n\nWhen you comitted ab41dfbfd4f3f9fedac71550027e9813b11abe3d, it extended\nquotemeta to where it shouldn't have been applied.\n\n    Luben\nP.S. When replying please don't redact the CC field.\n"},{"id":"28121","messageId":"200610022250.32029.jnareb@gmail.com","threadId":"5746","inReplyTo":"20061002201256.89409.qmail@web31809.mail.mud.yahoo.com","subject":"Re: gitweb: using quotemeta","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-02T20:50:31Z","receivedAt":"2006-10-02T20:50:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Luben Tuikov wrote:\n> --- Jakub Narebski <jnareb@gmail.com> wrote:\n>> Luben Tuikov wrote:\n>> \n>>> --- Junio C Hamano <junkio@cox.net> wrote:\n>>>> \n>>>> Ouch, that was a sloppy planning and coding, and sloppier\n>>>> reviewing.  Sorry.\n>>>> \n>>>> What is the right quoting there?  Just quoting double-quotes?\n>>> \n>>> I'm not sure.  What undesired character could we have in $filename\n>>> of a snapshot?  The commit ab41dfbfd4f message gives this\n>>> justification: \"Just in case filename contains end of line character.\"\n>>> \n>>> It looks like $filename is constructed by well defined strings:\n>>> basename($project), $hash and $suffix all of which should be ok.\n>>> \n>>> I'd say we don't need quotemeta for $filename of snapshot.\n>> \n>> But we do need quoting for blob_plain and perhaps blobdiff_plain\n>> views, although not quotemeta, but perhaps the reverse of unescape,\n>> i.e. quote '\"', EOLN (end of line) and perhaps also TAB.\n> \n> Escaping for the purposes of HTML _view_ and URL generation is ok,\n> but it is not ok when _saving_ the file with a file name.\n> \n> A file name is just a string of chars, and I want to _save_ the file\n> name as its name is. No changes or interpretations please.  I don't\n> care what the string is, what chars it is made of, etc.\n\nWe need to _escape_ HTML output (using esc_html subroutine) because\nHTML treats some characters specially, and we need to escape them\nto turn off this interpretation. Examples include SPC (for example\nfile name which has two consecutive spaces) and ampersand '&' which\nmight be treated as entity reference.\n\nSometimes we want to quote filename for view, for example to fit it\nin one line, and to distinguish between tab and spaces.\n\n\nBut you forget that in HTTP headers, to be more exact in\n\tContent-Disposition: inline; filename=\"<filename>\"\nheader, the quote '\"' and end-of-line '\\n' characters in <filename>\nare treated specially. So you need to quote somehow at least those\ntwo characters.\n\n\n<checks the RFC>\n\nRFC 2616 \"Hypertext Transfer Protocol -- HTTP/1.1\":\n   RFC 1806 [35], from which the often implemented Content-Disposition\n   (see section 19.5.1) header in HTTP is derived, has a number of very\n   serious security considerations. Content-Disposition is not part of\n   the HTTP standard, but since it is widely implemented, we are\n   documenting its use and risks for implementors. See RFC 2183 [49]\n   (which updates RFC 1806) for details.\n\nRFC 2183 \"Communicating Presentation Information in Internet Messages:\n          The Content-Disposition Header Field\":\n2.3  The Filename Parameter\n\n   The sender may want to suggest a filename to be used if the entity is\n   detached and stored in a separate file. If the receiving MUA writes\n   the entity to a file, the suggested filename should be used as a\n   basis for the actual filename, where possible.\n\n   It is important that the receiving MUA not blindly use the suggested\n   filename.  The suggested filename SHOULD be checked (and possibly\n   changed) to see that it conforms to local filesystem conventions,\n   does not overwrite an existing file, and does not present a security\n   problem (see Security Considerations below).\n\n   The receiving MUA SHOULD NOT respect any directory path information\n   that may seem to be present in the filename parameter.  The filename\n   should be treated as a terminal component only.  Portable\n   specification of directory paths might possibly be done in the future\n   via a separate Content-Disposition parameter, but no provision is\n   made for it in this draft.\n\n   Current [RFC 2045] grammar restricts parameter values (and hence\n   Content-Disposition filenames) to US-ASCII.  We recognize the great\n   desirability of allowing arbitrary character sets in filenames, but\n   it is beyond the scope of this document to define the necessary\n   mechanisms.  We expect that the basic [RFC 1521] `value'\n   specification will someday be amended to allow use of non-US-ASCII\n   characters, at which time the same mechanism should be used in the\n   Content-Disposition filename parameter.\n\n> Please don't interpret file names and their characters when the files\n> are _saved_ by the user's browser.\n>\n> The file name in my filesystem should be the exact same file name\n> as it appears on any other filesystem hosting the same git repo.\n\nAs you can see from the above RFC, there is no standard way to pass\nsuggested filename to be exactly the same as in git repository, if\nit contains non US-ASCII characters. At least not for _HTTP_ \nContent-Disposition: header; for email we can use quoted-printable\nfrom RFC 2047 to encode non US-ASCII characters (including \" and EOLN)\nwith good probability of this working correctly.\n \n> I don't want this translation:\n> Server FS: linux-2.6.git-5c2d97cb31fb77981797fec46230ca005b865799.tar.gz\n> Quotemeta: linux\\-2\\.6\\.git\\-5c2d97cb31fb77981797fec46230ca005b865799\\.tar\\.gz\n> User FS: linux\\-2\\.6\\.git\\-5c2d97cb31fb77981797fec46230ca005b865799\\.tar\\.gz\n> \n> When you comitted ab41dfbfd4f3f9fedac71550027e9813b11abe3d, it extended\n> quotemeta to where it shouldn't have been applied.\n\nI only followed (I admit blindly, without checking the details, and\nI agree wrongly) the commit a2f3db2f5de2a3667b0e038aa65e3e097e642e7d\n   \"gitweb: Consolidate escaping/validation of query string\"\nby Petr \"Pasky\" Baudis, which among others included the following patch\n(which part of commit is not documented enough in commit message):\n\n@@ -3126,7 +3116,7 @@ sub git_blobdiff {\n \t\t\t-type => 'text/plain',\n \t\t\t-charset => 'utf-8',\n \t\t\t-expires => $expires,\n-\t\t\t-content_disposition => qq(inline; filename=\"${file_name}.patch\"));\n+\t\t\t-content_disposition => qq(inline; filename=\") . quotemeta($file_name) . qq(.patch\"));\n \n \t\tprint \"X-Git-Url: \" . $cgi->self_url() . \"\\n\\n\";\n \n\nAnd I agree that your\n   \"gitweb: Don't use quotemeta on internally generated strings\"\nis (partially) correct.\n\n>     Luben\n> P.S. When replying please don't redact the CC field.\n\nWhen I reply by email, I have no problem (I have to add git\nmailing list if I forget to use reply to all). When I reply\nvia GMane NNTP interface, KNode by default replies only to\nnewsgroup (coupled with git mailing list).\n-- \nJakub Narebski\nPoland\n"},{"id":"28131","messageId":"7vven1syg0.fsf@assigned-by-dhcp.cox.net","threadId":"5746","inReplyTo":"200610022250.32029.jnareb@gmail.com","subject":"Re: gitweb: using quotemeta","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-03T06:30:55Z","receivedAt":"2006-10-03T06:30:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> But you forget that in HTTP headers, to be more exact in\n> \tContent-Disposition: inline; filename=\"<filename>\"\n> header, the quote '\"' and end-of-line '\\n' characters in <filename>\n> are treated specially. So you need to quote somehow at least those\n> two characters.\n\nTrue, but untrue.  This is just a suggestion so we do not _have_\nto quote.  We only need to avoid spitting out dq and lf\nliterally.  We could even just do something like the attached if\nwe wanted to:\n\n\ts/[^ -~]+/?/g\t;# replace each sequence of bytes outside\n        \t\t # ' ' to '~' range to a '?'\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex 44991b1..e7202ee 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -2651,7 +2651,7 @@ sub git_blob_plain {\n \t# save as filename, even when no $file_name is given\n \tmy $save_as = \"$hash\";\n \tif (defined $file_name) {\n-\t\t$save_as = $file_name;\n+\t\t($save_as = $file_name) =~ s/[^ -~]+/?/g;\n \t} elsif ($type =~ m/^text\\//) {\n \t\t$save_as .= '.txt';\n \t}\n@@ -2830,6 +2830,7 @@ sub git_snapshot {\n \t}\n \n \tmy $filename = basename($project) . \"-$hash.tar.$suffix\";\n+\t$filename =~ s/[^ -~]+/?/g;\n \n \tprint $cgi->header(\n \t\t-type => 'application/x-tar',\n@@ -3139,6 +3140,7 @@ sub git_blobdiff {\n \t\t}\n \n \t} elsif ($format eq 'plain') {\n+\t\t$file_name =~ s/[^ -~]+/?/g;\n \t\tprint $cgi->header(\n \t\t\t-type => 'text/plain',\n \t\t\t-charset => 'utf-8',\n@@ -3241,6 +3243,7 @@ sub git_commitdiff {\n \t\tmy $refs = git_get_references(\"tags\");\n \t\tmy $tagname = git_get_rev_name_tags($hash);\n \t\tmy $filename = basename($project) . \"-$hash.patch\";\n+\t\t$filename =~ s/[^ -~]+/?/g;\n \n \t\tprint $cgi->header(\n \t\t\t-type => 'text/plain',\n"},{"id":"28283","messageId":"200610061438.50965.jnareb@gmail.com","threadId":"5746","inReplyTo":"7vven1syg0.fsf@assigned-by-dhcp.cox.net","subject":"Re: gitweb: using quotemeta","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-06T12:38:50Z","receivedAt":"2006-10-06T12:38:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski <jnareb@gmail.com> writes:\n> \n>> But you forget that in HTTP headers, to be more exact in\n>>       Content-Disposition: inline; filename=\"<filename>\"\n>> header, the quote '\"' and end-of-line '\\n' characters in <filename>\n>> are treated specially. So you need to quote somehow at least those\n>> two characters.\n> \n> True, but untrue.  This is just a suggestion so we do not _have_\n> to quote.  We only need to avoid spitting out dq and lf\n> literally.  We could even just do something like the attached if\n> we wanted to:\n> \n>         s/[^ -~]+/?/g   ;# replace each sequence of bytes outside\n>                          # ' ' to '~' range to a '?'\n> \n> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\n> index 44991b1..e7202ee 100755\n> --- a/gitweb/gitweb.perl\n> +++ b/gitweb/gitweb.perl\n> @@ -2651,7 +2651,7 @@ sub git_blob_plain {\n>         # save as filename, even when no $file_name is given\n>         my $save_as = \"$hash\";\n>         if (defined $file_name) {\n> -               $save_as = $file_name;\n> +               ($save_as = $file_name) =~ s/[^ -~]+/?/g;\n>         } elsif ($type =~ m/^text\\//) {\n>                 $save_as .= '.txt';\n>         }\n\nI'd rather add (and use) separate subroutine for quoting/escaping\nvalues in HTTP headers, or to be more exact for the filename part\nof HTTP header \"Content-Disposition:\". This way if we decide to\nnot replace all characters outside US-ASCII in suggested filename\nto save with '?', but only qoublequote '\"' and linefeed '\\n' characters,\nor even implement RFC 2047 to do the encoding (of course if browsers\ncan read it), we could do this in one place. \n\nHow such a subroutine should be named? esc_http? esc_header or esc_hdr?\nesc_http_header? Any other ideas?\n-- \nJakub Narebski\nPoland\n"},{"id":"28286","messageId":"20061006135019.GN20017@pasky.or.cz","threadId":"5746","inReplyTo":"20061002201256.89409.qmail@web31809.mail.mud.yahoo.com","subject":"Re: gitweb: using quotemeta","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-06T13:50:19Z","receivedAt":"2006-10-06T13:50:19Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Oct 02, 2006 at 10:12:56PM CEST, I got a letter\nwhere Luben Tuikov <ltuikov@yahoo.com> said that...\n> Escaping for the purposes of HTML _view_ and URL generation is ok,\n> but it is not ok when _saving_ the file with a file name.\n> \n> A file name is just a string of chars, and I want to _save_ the file\n> name as its name is. No changes or interpretations please.  I don't\n> care what the string is, what chars it is made of, etc.\n> \n> Please don't interpret file names and their characters when the files\n> are _saved_ by the user's browser.\n> \n> The file name in my filesystem should be the exact same file name\n> as it appears on any other filesystem hosting the same git repo.\n> \n> I don't want this translation:\n> Server FS: linux-2.6.git-5c2d97cb31fb77981797fec46230ca005b865799.tar.gz\n> Quotemeta: linux\\-2\\.6\\.git\\-5c2d97cb31fb77981797fec46230ca005b865799\\.tar\\.gz\n> User FS: linux\\-2\\.6\\.git\\-5c2d97cb31fb77981797fec46230ca005b865799\\.tar\\.gz\n\nThen the user agent is buggy - which browser exhibits this behaviour?\n\nAccording to RFC2183, the filename is a value. According to RFC2045, a\nvalue is either a token (uninteresting) or a quoted-string. According to\nRFC822:\n\n     quoted-string = <\"> *(qtext/quoted-pair) <\">; Regular qtext or\n                                                 ;   quoted chars.\n\n     qtext       =  <any CHAR excepting <\">,     ; => may be folded\n                     \"\\\" & CR, and including\n                     linear-white-space>\n\n     quoted-pair =  \"\\\" CHAR                     ; may quote any char\n\nSo what we emit is completely correct.\n\nOf course I have nothing against escaping just \", \\ and CR. I don't mind\njust substituting CR with some other string, but please just quote \" and\n\\ correctly.\n\nAs of now, gitweb will not handle any filenames containing those three\ncharacters properly because of now.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj\n$/=unpack('H*',$_);$_=`echo 16dio\\U$k\"SK$/SM$n\\EsN0p[lN*1\nlK[d2%Sa2/d0$^Ixp\"|dc`;s/\\W//g;$_=pack('H*',/((..)*)$/)\n"},{"id":"28309","messageId":"20061006182105.17519.qmail@web31806.mail.mud.yahoo.com","threadId":"5746","inReplyTo":"20061006135019.GN20017@pasky.or.cz","subject":"Re: gitweb: using quotemeta","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-06T18:21:05Z","receivedAt":"2006-10-06T18:21:05Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Petr Baudis <pasky@suse.cz> wrote:\n> Dear diary, on Mon, Oct 02, 2006 at 10:12:56PM CEST, I got a letter\n> where Luben Tuikov <ltuikov@yahoo.com> said that...\n> > Escaping for the purposes of HTML _view_ and URL generation is ok,\n> > but it is not ok when _saving_ the file with a file name.\n> > \n> > A file name is just a string of chars, and I want to _save_ the file\n> > name as its name is. No changes or interpretations please.  I don't\n> > care what the string is, what chars it is made of, etc.\n> > \n> > Please don't interpret file names and their characters when the files\n> > are _saved_ by the user's browser.\n> > \n> > The file name in my filesystem should be the exact same file name\n> > as it appears on any other filesystem hosting the same git repo.\n> > \n> > I don't want this translation:\n> > Server FS: linux-2.6.git-5c2d97cb31fb77981797fec46230ca005b865799.tar.gz\n> > Quotemeta: linux\\-2\\.6\\.git\\-5c2d97cb31fb77981797fec46230ca005b865799\\.tar\\.gz\n> > User FS: linux\\-2\\.6\\.git\\-5c2d97cb31fb77981797fec46230ca005b865799\\.tar\\.gz\n> \n> Then the user agent is buggy - which browser exhibits this behaviour?\n\nLatest greatest Firefox for Linux.  And no, I don't think that\nthe browser is broken.\n\n> According to RFC2183, the filename is a value. According to RFC2045, a\n> value is either a token (uninteresting) or a quoted-string. According to\n> RFC822:\n> \n>      quoted-string = <\"> *(qtext/quoted-pair) <\">; Regular qtext or\n>                                                  ;   quoted chars.\n> \n>      qtext       =  <any CHAR excepting <\">,     ; => may be folded\n>                      \"\\\" & CR, and including\n>                      linear-white-space>\n> \n>      quoted-pair =  \"\\\" CHAR                     ; may quote any char\n> \n> So what we emit is completely correct.\n\n(Your quotations do not seem correct according to \n  ftp://ftp.rfc-editor.org/in-notes/rfc2045.txt !)\n\nPetr, I agree with your that what we emit is \"completely correct\".\n\nBut is is _mangled_.  I.e. why mangle the filename from \"a.b\" to\n\"a\\.b\" ?  Indeed the latter _is_ qtext but it is not the original name\ngiven to the file.\n\nWhat actually happened is that _gitweb_ itself mangles the name.\n\n> Of course I have nothing against escaping just \", \\ and CR. I don't mind\n> just substituting CR with some other string, but please just quote \" and\n> \\ correctly.\n\nIndeed, these three are the only chars NOT ALLOWED in qtext.\nWill quote those.  Thanks for pointing this out.\n\n> As of now, gitweb will not handle any filenames containing those three\n> characters properly because of now.\n\nWill fix.\n\nThanks,\n   Luben\n\n\n\n> \n> -- \n> \t\t\t\tPetr \"Pasky\" Baudis\n> Stuff: http://pasky.or.cz/\n> #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj\n> $/=unpack('H*',$_);$_=`echo 16dio\\U$k\"SK$/SM$n\\EsN0p[lN*1\n> lK[d2%Sa2/d0$^Ixp\"|dc`;s/\\W//g;$_=pack('H*',/((..)*)$/)\n> \n"},{"id":"28338","messageId":"7vr6xkzpak.fsf@assigned-by-dhcp.cox.net","threadId":"5746","inReplyTo":"200610061438.50965.jnareb@gmail.com","subject":"Re: gitweb: using quotemeta","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-07T05:08:03Z","receivedAt":"2006-10-07T05:08:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> I'd rather add (and use) separate subroutine for quoting/escaping\n> values in HTTP headers, or to be more exact for the filename part\n> of HTTP header \"Content-Disposition:\". This way if we decide to\n> not replace all characters outside US-ASCII in suggested filename\n> to save with '?', but only qoublequote '\"' and linefeed '\\n' characters,\n> or even implement RFC 2047 to do the encoding (of course if browsers\n> can read it), we could do this in one place. \n\nSounds sane.  quote_filename?\n"},{"id":"28349","messageId":"200610071123.23654.jnareb@gmail.com","threadId":"5746","inReplyTo":"7vr6xkzpak.fsf@assigned-by-dhcp.cox.net","subject":"Re: gitweb: using quotemeta","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-07T09:23:23Z","receivedAt":"2006-10-07T09:23:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski <jnareb@gmail.com> writes:\n> \n>> I'd rather add (and use) separate subroutine for quoting/escaping\n>> values in HTTP headers, or to be more exact for the filename part\n>> of HTTP header \"Content-Disposition:\". This way if we decide to\n>> not replace all characters outside US-ASCII in suggested filename\n>> to save with '?', but only qoublequote '\"' and linefeed '\\n' characters,\n>> or even implement RFC 2047 to do the encoding (of course if browsers\n>> can read it), we could do this in one place. \n> \n> Sounds sane.  quote_filename?\n\nLuben Tuikov used  to_qtext  in\n  \"[PATCH] gitweb: Convert Content-Disposition filenames into qtext\"\n  Msg-ID: <20061006191801.68649.qmail@web31815.mail.mud.yahoo.com>\n  http://permalink.gmane.org/gmane.comp.version-control.git/28437\n\n-- \nJakub Narebski\nPoland\n"},{"id":"28373","messageId":"20061007174121.44284.qmail@web31813.mail.mud.yahoo.com","threadId":"5746","inReplyTo":"200610071123.23654.jnareb@gmail.com","subject":"Re: gitweb: using quotemeta","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-07T17:41:21Z","receivedAt":"2006-10-07T17:41:21Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Jakub Narebski <jnareb@gmail.com> wrote:\n> Junio C Hamano wrote:\n> > Jakub Narebski <jnareb@gmail.com> writes:\n> > \n> >> I'd rather add (and use) separate subroutine for quoting/escaping\n> >> values in HTTP headers, or to be more exact for the filename part\n> >> of HTTP header \"Content-Disposition:\". This way if we decide to\n> >> not replace all characters outside US-ASCII in suggested filename\n> >> to save with '?', but only qoublequote '\"' and linefeed '\\n' characters,\n> >> or even implement RFC 2047 to do the encoding (of course if browsers\n> >> can read it), we could do this in one place. \n> > \n> > Sounds sane.  quote_filename?\n> \n> Luben Tuikov used  to_qtext  in\n>   \"[PATCH] gitweb: Convert Content-Disposition filenames into qtext\"\n>   Msg-ID: <20061006191801.68649.qmail@web31815.mail.mud.yahoo.com>\n>   http://permalink.gmane.org/gmane.comp.version-control.git/28437\n\nI think that people familiar with the RFC will be able to quickly\nrecognize what this function does, after seeing \"qtext\" in the\nname of the function.  After all, not only filenames can be qtext.\n\n    Luben\n"},{"id":"28593","messageId":"200610111148.31490.jnareb@gmail.com","threadId":"5746","inReplyTo":"20061007174121.44284.qmail@web31813.mail.mud.yahoo.com","subject":"Re: gitweb: using quotemeta","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-11T09:48:31Z","receivedAt":"2006-10-11T09:48:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Luben Tuikov wrote:\n> > Luben Tuikov used  to_qtext  in\n> >   \"[PATCH] gitweb: Convert Content-Disposition filenames into qtext\"\n> >   Msg-ID: <20061006191801.68649.qmail@web31815.mail.mud.yahoo.com>\n> >   http://permalink.gmane.org/gmane.comp.version-control.git/28437\n> \n> I think that people familiar with the RFC will be able to quickly\n> recognize what this function does, after seeing \"qtext\" in the\n> name of the function.  After all, not only filenames can be qtext.\n\nIt wasn't meant to criticize. Just pointing out. It is nice\nnaming scheme (to_qtext, to_utf8) in addition to esc_* naming scheme.\nI had no good idea for esc_* naming scheme for to_qtext subroutine...\nso to_qtext is better.\n-- \nJakub Narebski\nPoland\n"}]}