Hey Justin, In the case you mention, it is mostly backwards compatible - the original preferred headers are respected if the Response returns null from getAttachmentFileName. This has to be implemented in the Response subclass, though, since the default is to compute a filename based on operation and mimetype. The latter could be changed, but it seemed like a balance between getting useful default behavior or preserving the old behavior - which in almost all of the cases was trivial to upgrade. In other words, change the Response base class behavior to opt-in versus opt-out.
As for the client overriding the preferred type (or headers via old API), that was the intention of the changes. On Wed, Jul 27, 2011 at 9:11 AM, Justin Deoliveira <[email protected]> wrote: > Hi Ian, > So are you saying that the change is backward compatible with existing > Responses/output formats that use getHeaders() to set the content > dispotiion. Looking at the patch (and maybe I am not looking close enough) > it seems like the new api will overwrite in the case where the client > specifies the content-disposition flag? > Excuse the noise if i am missing something. > On Tue, Jul 26, 2011 at 8:58 PM, Ian Schneider <[email protected]> > wrote: >> >> Hi everyone, >> >> While committing my patches for >> http://jira.codehaus.org/browse/GEOS-4683, I broke the build. This was >> resolved fairly quickly (note to self - run maven just like hudson >> does) but made me realize these changes were worth a heads up to >> anyone authoring OWS Response subclasses. >> >> For details see the OWS Dispatcher and the Response javadoc, but the >> gist is that previously each Response subclass was handling >> Content-Disposition headers via the getHeaders method. The new >> behavior is that the Dispatcher uses the new API to determine a >> filename, and if not null, the preferred disposition type (attachment >> or the default, inline). If the request provides the >> content-disposition header parameter (either inline or attachment with >> header injection checking) then this is respected over the Response >> preference. >> >> I handled most of the Response subclasses and the tests. This is a >> heads up for existing maintainers on the changes as well as for new >> implementations. >> >> On a related note, it is not clear whether the filename should be >> quoted or encoded, but this patch will at least make that >> cross-cutting concern easier to address at some point (though it >> requires a number of test case adjustments). >> >> Thanks for bearing with me and comments much appreciated, >> -Ian >> >> -- >> Ian Schneider >> OpenGeo - http://opengeo.org >> Enterprise support for open source geospatial. >> >> >> ------------------------------------------------------------------------------ >> Got Input? Slashdot Needs You. >> Take our quick survey online. Come on, we don't ask for help often. >> Plus, you'll get a chance to win $100 to spend on ThinkGeek. >> http://p.sf.net/sfu/slashdot-survey >> _______________________________________________ >> Geoserver-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > -- Ian Schneider OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
