The Tomcat specific javadoc for Servlet 3.1 is not synced with the official Servlet spec 3.1 properly. See https://github.com/apache/tomcat85/blob/trunk/java/javax/servlet/http/Part.java#L88-L90 The official spec says ... http://docs.oracle.com/javaee/7/api/javax/servlet/http/Part.html#write-java.lang.String- The use of Part.write(String) is always relative to the MultiPartConfig.location, its never absolute. Issue https://bz.apache.org/bugzilla/show_bug.cgi?id=54203 attempted to fix this. Resulting in commit https://github.com/apache/tomcat85/commit/073b311fd4f5650c68a0c61f9baf4d195775405a which looks like you pulled a draft version of the Part javadoc, not the official final version.
It is not just the javadoc. Also the behavior is different - when a File with an absolute path is passed it is used as is. When a file with relative path is passed then the config location is used as a parent. Honestly I do like this behavior! But I guess it should be removed since it is against the spec.
Tomcat can't copy the Javadoc verbatim from the reference implementation due to licencing. It is different for the text the Sun contributed back when Tomcat was the reference implementation but that doesn't apply here. I don't see any text in the referenced Javadoc that says "The use of Part.write(String) is always relative to the MultiPartConfig.location, its never absolute." Where is this requirement coming from? My reading of the Javadoc is that Tomcat's implementation is spec compliant.
Glassfish, Resin, and Jetty implement it according to the javadoc. It's always relative to the MultiPartConfig.location Glassfish calls that location 'repository' see PartItem.java Jetty calls that location `_tmpDir` see MultiPartInputStreamParser.MultiPart Resin calls that location `location` see HttpServletRequestImpl.PartImpl Undertow implements it according to your interpretation (they seem to have followed your lead). The official servlet spec 3.1 final pdf also makes no statement on the behavior of that method. Only that the MultiPartConfig.location must have a value, and it goes through the default value and how to interpret the setting that the user has provided. I have no access to the Servlet TCK to confirm the behavior in there. But seeing as Glassfish interprets it the same way as the javadoc, I would probably guess that the odds on the Glassfish/Resin/Jetty interpretation is the correct way. Perhaps this needs a SERVLET_SPEC jira issue opened on it?
I thought this had been discussed a little before https://bz.apache.org/bugzilla/show_bug.cgi?id=54971#c3 From (rather hazy) memory, the reason for that was that Commons File Upload allowed absolute paths and Tomcat allowing it here eased the migration path. I'll add that the spec doesn't say how to handle the application passing an absolute path. You could make the case that the behaviour is undefined and in that case and the container is free to do as it chooses. Equally, you could argue anything that isn't a relative file name is an error that should trigger an IOException. At the extreme, you could argue anything that isn't a pure filename with no path is an error. I don't see any discussion around this particular point in the Servlet EG. Now is certainly the time to open an issue if you'd like clarification since the EG is fairly active at the moment.