If the name or extensions are vital to the service then it should be part of the specification that defines that service's interface and thus either implied as part of that specification or contained in the SOAP envelope. Doing something like this automatically as part of Axis implementation would promote the development of services on Axis that was not portable with other SOAP implementations and thus IMO should be avoided. Using HEADERS does not extend to DIME attachments which is another reason I'm opposed to this solution.
>+1. some kind of metadata is needed.
>- James Snell
>IBM Emerging Technologies
>[EMAIL PROTECTED]
>(559) 587-1233 (office)
>(700) 544-9035 (t/l)
>Programming Web Services With SOAP
>O'Reilly & Associates, ISBN 0596000952
>Have I not commanded you? Be strong and courageous.
>Do not be terrified, do not be discouraged, for the Lord your
>God will be with you whereever you go. - Joshua 1:9
>
>Jess Sightler <[EMAIL PROTECTED]>
>01/30/2003 02:00 PM
>Please respond to axis-dev
>
>To
>[EMAIL PROTECTED]
>cc
>bcc
>Subject
>Re: Axis attachment naming enhancement (code attached)
>
>Perhaps the real solution is to make Axis store the filename somewhere
>(perhaps in a file like Axis98765axis.properties)? I agree that letting
>the client control the server filename is a security risks, but carrying
>meta-data, such as whether or not the file is a .exe file) is useful.
>
>On Thu, 2003-01-30 at 16:43, James M Snell wrote:
>> I would think that allowing the client to control the naming of the
>files
>> saved on the server would constitute a security risk on the server. If
>> the attachment contains a malicious executable, then Axis would be
>> unwittingly allowing the code to be saved to the server in a form that
>> would allow it to be easily executed (e.g. tempfilename.exe). While I
>> recognize the benefits that something like this would allow, I do not
>> believe that this is the right solution.
>>
>> - James Snell
>> IBM Emerging Technologies
>> [EMAIL PROTECTED]
>> (559) 587-1233 (office)
>> (700) 544-9035 (t/l)
>> Programming Web Services With SOAP
>> O'Reilly & Associates, ISBN 0596000952
>>
>> Have I not commanded you? Be strong and courageous.
>> Do not be terrified, do not be discouraged, for the Lord your
>> God will be with you whereever you go. - Joshua 1:9
>>
>>
>>
>> Jim Lerner <[EMAIL PROTECTED]>
>> 01/30/2003 12:10 PM
>> Please respond to axis-dev
>>
>>
>> To
>> [EMAIL PROTECTED]
>> cc
>>
>> bcc
>>
>> Subject
>> Axis attachment naming enhancement (code attached)
>>
>>
>>
>>
>>
>> I am submitting for your approval (and integration) changes to
>> Axis-1_1beta that allows Axis to create unique names for file
>> attachments that bear a passing resemblance to the original filename.
>> This is critical for applications that use the filename [extension] for
>> disambiguation, and also in the case of multiple attachments on a single
>> message. It's my understanding that there are a number of Axis users
>> out there who have suffered for lack of a solution to this problem.
>>
>> The premise is simple: add a MIME header to each attachment with the
>> original filename. When the file is sent to Axis, Axis'
>> ManagedMemoryDataSource will use this name to create a uniquely named
>> temporary file (eg. Axis98765_myfile.xls) rather than the usual
>> (Axis98765axis). Likewise, when Axis receives a file to be sent back to
>> the caller, a MIME header on the attachment indicates the original name
>> (Axis98765_myfile.xls). This is not quite optimal, but it is easy
>> enough for the client to parse and use, given that the underscore is
>> guaranteed to be the first one in the filename. Existing applications
>> that don't set the MIME header will continue to see the previous file
>> naming behavior.
>>
>> The changes that I've made (in the attached files) are as follows:
>>
>> org/apache/axis/transport/http/HTTPConstants:
>> added HEADER_X_ORIGINAL_FILENAME for new MIME header
>>
>> org/apache/axis/attachments/AttachmentPart:
>> setMimeHeader(DataSource's getName()) when creating an attachment part
>> from a DataHandler and
>> when setting a DataHandler for an existing AttachmentPart.
>>
>> org/apache/axis/attachments/MultiPartRelatedInputStream:
>> inform ManagedMemoryDataSource of the X_ORIGINAL_FILENAME MIME heading.
>>
>> org/apache/axis/attachments/ManagedMemoryDataSource:
>> added new constructor with extra parameter for original name (other
>> constructors use this(..., null))
>> added storage for the original filename
>> use the original name when constructing the temporary file into which
>> the in-memory file is flushed.
>>
>> Please let me know if you need any further clarification, any of this
>> needs to be reworked, etc. I'm hoping that you'll find this to be
>> useful, correct, and worth integrating into the CVS repository.
>>
>> - Jim
>>
>>
>>
>>
>>
>>
>>
>--
>=======================================
>Jess Sightler
>Senior Developer
>Exim Technologies
>131 Falls Street
>Greenville SC 29601
>Phone: 864-679-4651
>=======================================
>
>
Rick Rineholt
"The truth is out there... All you need is a better search engine!"
[EMAIL PROTECTED]
- RE: Axis attachment naming enhancement (code attache... Vidyanand Murunikkara
- Re: Axis attachment naming enhancement (code at... Rick Rineholt
- Re: Axis attachment naming enhancement (code at... Steve Loughran
- Re: Axis attachment naming enhancement (code at... Jess Sightler
- Re: Axis attachment naming enhancement (cod... James M Snell
- Re: Axis attachment naming enhancement ... Steve Loughran
- RE: Axis attachment naming enhancement (code at... Joseph Carew
- Re: Axis attachment naming enhancement (code at... Jim Lerner
- Re: Axis attachment naming enhancement (cod... Steve Loughran
- Re: Axis attachment naming enhancement (code at... Rick Rineholt
- Re: Axis attachment naming enhancement (cod... Steve Loughran