[Geoserver-devel] Forcing download of files on 2.1.x as well

GeoServer GeoServer Developer
1

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

Opinions?

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

2

+1

GeoServer should honour the client request where it can. The only problem I can think of is where a client requests a non-streamable format and there are many features, resulting in possible resource exhaustion on the server side due to the large size of the unanticipated response format. I think we have sufficient limits set in the server. If you think this is a problem, we could add an option to disable it, but I do not think it is necessary at first.

Kind regards,
Ben.

On 25/10/11 16:18, Andrea Aime 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

Opinions?

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

-------------------------------------------------------

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

3

On Tue, Oct 25, 2011 at 10:34 AM, Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com wrote:

+1

GeoServer should honour the client request where it can. The only
problem I can think of is where a client requests a non-streamable
format and there are many features, resulting in possible resource
exhaustion on the server side due to the large size of the unanticipated
response format. I think we have sufficient limits set in the server. If
you think this is a problem, we could add an option to disable it, but I
do not think it is necessary at first.

Ah, this is not really a problem. Downloadable just means setting a single
http header, the content disposition one, so that the browser will propose
the user to save the file on disk instead of showing it inline.
It does not prevent streaming at all, nor does require the file to be saved
on the server side.

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

4

+1

On Tue, Oct 25, 2011 at 6:13 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Oct 25, 2011 at 10:34 AM, Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com wrote:

+1

GeoServer should honour the client request where it can. The only
problem I can think of is where a client requests a non-streamable
format and there are many features, resulting in possible resource
exhaustion on the server side due to the large size of the unanticipated
response format. I think we have sufficient limits set in the server. If
you think this is a problem, we could add an option to disable it, but I
do not think it is necessary at first.

Ah, this is not really a problem. Downloadable just means setting a single
http header, the content disposition one, so that the browser will propose
the user to save the file on disk instead of showing it inline.
It does not prevent streaming at all, nor does require the file to be saved
on the server side.

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

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@anonymised.com Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

5

+1 on the idea with a few comments.

On Tue, Oct 25, 2011 at 9:18 AM, Andrea Aime <andrea.aime@anonymised.com> 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.

+1 on the general backport though.

Opinions?

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

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@anonymised.com Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

6

On Wed, Oct 26, 2011 at 8:01 AM, Justin Deoliveira <jdeolive@anonymised.com.1501…> wrote:

+1 on the idea with a few comments.

On Tue, Oct 25, 2011 at 9:18 AM, Andrea Aime <andrea.aime@anonymised.com> 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?

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

7

On Wed, Oct 26, 2011 at 7:55 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, Oct 26, 2011 at 8:01 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

+1 on the idea with a few comments.

On Tue, Oct 25, 2011 at 9:18 AM, Andrea Aime <andrea.aime@anonymised.com> 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.