On Wed, Oct 26, 2011 at 7:55 AM, Andrea Aime
<[email protected]>wrote:
> On Wed, Oct 26, 2011 at 8:01 AM, Justin Deoliveira
> <[email protected]>wrote:
>
>> +1 on the idea with a few comments.
>>
>> On Tue, Oct 25, 2011 at 9:18 AM, Andrea Aime <
>> [email protected]> wrote:
>>
>>> Hi,
>>> on trunk we now have the possibility to force the download of a file that
>>> the browser
>>> would otherwise open inline adding the "&content-disposition=attachment"
>>> kvp param
>>> to any request.
>>>
>>> I need the same to work on 2.1.x as well, but I'm weary of backporting
>>> the large patch
>>> that landed on trunk.
>>>
>>> I was wondering about the following:
>>> - adding on 2.1.x two new parameters
>>> content-disposition=(attachment|inline) and
>>> filename (so that the caller can force a specific file name)
>>>
>>
>>
>>> - modifying trunk to handle the filename param as well, and make the two
>>> works
>>> as orders, not as suggestions (now they are used only if the response
>>> does not
>>> provide its own, which I find a bit odd since the client told us us
>>> what to do already
>>>
>> Perhaps I don't understand... but why the need for a separate filename
>> parameter? What about just using the syntax defined in rfc 2183 for content
>> disposition? I guess perhaps the issue is the "=" that has to be url
>> encoded? Could be a nice way to leave the door open though in case we want
>> to support other parameters to the content-disposition header other than
>> just filename.
>>
>
> I see, I did not think of it in that terms because I based my proposal on
> the current trunk code, which needs
> the two as separate tokens.
> Your comment prompted me to look into the spec, here:
> http://www.ietf.org/rfc/rfc2183.txt
>
> and it's indeed possible to specify stuff other than the file name itself.
>
> So, on trunk the issue I see is that if the user did not specify the file
> name, but other fields, we'd
> first have to parse the content-disposition header into its component parts
> and then decided
> wheter to use an eventually user provided file name or see if the response
> has one for us.
>
> Parsing can be made annoying by the fact rfc2183 does not explicitly forbid
> ";" and ":"
> as a chars in the filename, nor it talks about escaping, not sure how
> browsers handle that case though.
>
> I also don't see a need to use any of the other content disposition params
> in HTTP, especially if they
> are user provided (some of them can be precisely known only by the server).
>
> Long story short, I can go for a generic spec of the content disposition
> header by the user,
> but it seems a bit overkill to me.
>
> Opinions?
>
Fair enough... just a suggestion. Sort of seemed like we were reinventing
the wheel a bit. No strong opinion.
>
> Cheers
> Andrea
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
