Zip-File stored in Mime-Repository ?

[Former Member]

Hi all,

has anyone ever tried to store a zip-file in the mime-repository and access it afterwards via web-browser ?

I encounter problems downloading the zip-file with the webbrowser (exactly opening it afterwards) !

- the upload in the mime-repository works fine

- I can also access the zip-file correctly using SAP-GUI

- problem occurs when using webbrowser to access the zip-file

I have found a list of possible mimetypes in the mime repository, zip was NOT one of them. Does this mean that storing/accessing zip-files in the mime repository is not possible ?

I have checked the original file and the downloaded file and found that on binary level they are not the same !

I have then renamed the file to .xls and the file content (binary) stays the same then, no problem with this mimetype.

Anyhow it seems to me that WAS somehow screws up the file when encountering .zip ending.

Can anyone help ?

Thanks a lot

Stefan

[RieSe]

Hi,

my comments to this:

We are running 6.20 on SP42. Placing a zip file into the mimerep and double-clicking on it: the workbench offers the right file, but with a complete other (not readable) name. But the content is ok.

Accessing in the webbrowser is not possible as you described.

I have done the following, because i cannot wait for new kernels:

ZIP-Files are categorized in the Mime-repo as 'M_APP_P'.

(see txn DMWB, where you can find all mime-type handled by the Mime-Rep).

You can find this information also in the last tab, when doing a right mouse click on this opbject in the mime repo.

Also where is a physical-objectid, something like 4152219359DE72E1E10000000A35E047. ´thats a worldwide unique id.

With this two informations you can doing the follwing:

...

• Set target phio.

component-objid = objid.

component-class = class.

APPEND component TO components.

CALL FUNCTION 'SKWF_PHIOS_FILE_PROPERTIES_GET'

IMPORTING

error = error

TABLES

components = components.

IF error-type CN 'EA'.

READ TABLE components INTO component INDEX 1.

mime_type = component-mimetype.

file_size = component-file_size.

file_name = component-file_name.

MOVE-CORRESPONDING component TO phio.

CALL FUNCTION 'SKWF_PHIO_CONTENT_URL_GET'

EXPORTING

phio = phio

x_web_applic_server_url_only = 'X'

x_url_for_get = 'X'

x_no_cache = 'X' "x_standard_url_only = 'X'

IMPORTING

error = error

TABLES

urls = comp_urls.

READ TABLE comp_urls INTO comp_url INDEX 1.

IF sy-subrc = space.

url = comp_url-url.

ENDIF.

ENDIF.

....

Now you have a url.

[<%=file_name%> | <%=url%>]

does now the right thing.

What happens in detail.

The WAS implements the contentserver interface. Look at SICF.

You can find, that the use the handler CL_HTTP_EXT_CSIF.

Check out method IF_HTTP_EXTENSION~HANDLE_REQUEST.

Inside method PROCESS_GET is called. You have to repair them:

l_size_s = l_size.

l_length_s = l_length.

*{ INSERT DWAK901503 1

DATA:

l_saveas TYPE string.

CONCATENATE 'inline; filename="' l_compid '"' INTO l_saveas.

call method l_entity->set_header_field

exporting

name = 'Content-Disposition'

value = l_saveas .

*} INSERT

call method l_entity->set_header_field:

exporting name = 'Content-Type' value = l_mimetype, "#EC NOTEXT

exporting name = 'Content-Length' value = l_length_s, "#EC NOTEXT

exporting name = 'X-compId' value = l_compid, "#EC NOTEXT

exporting name = 'X-Content-Length' value = l_size_s, "#EC NOTEXT

exporting name = 'X-compDateC' value = l_datec, "#EC NOTEXT

exporting name = 'X-compTimeC' value = l_timec, "#EC NOTEXT

exporting name = 'X-compDateM' value = l_datem, "#EC NOTEXT

exporting name = 'X-compTimeM' value = l_timem, "#EC NOTEXT

exporting name = 'X-compStatus' value = l_status, "#EC NOTEXT

exporting name = 'X-pVersion' value = l_pversion. "#EC NOTEXT

Why? Because if you use my way, you get not the right filenames offered. With this repair all is right.

Don't worry: This will become standard in the next SP.

Hope this helps,

Stefan

[Former Member]

Hi all,

thanks a lot for your comments. SAP has confirmed that the kernel patch fixing this problem will be available within two weeks (also for 6.20). So I think we will wait until then.

Brian: currently we have some big issues about performance here. And I will prefer delaying the possibility to use .zip-files in mime repository to slowing down our site. No experiments at this stage...

Wolfgang: I have also thought about this, but this would mean changing application logic completely, which is not really worth the effort.

Stefan: sounds good, though I will prefer not to change anything, but wait for the kernel patch.

I think I can delay the colleagues who want to work with zip-files

Thanks anyway!

Regards,

Stefan

[Former Member]

Finally!

See SAP Note 775505

Kernel Patch 1673 (6.20; Patch 38 for 6.40) required to solve this !

Regards,

Stefan Hester

[Former Member]

Why dont you store the file with the business document service ??

I did it this way and had no problems !!

[Former Member]

Thanks for your reply. I had already checked OSS and didn't find anything suitable. The one note you mention deals with the storage of zip-files and that works fine.

I think I will open an OSS-ticket.

Thanks anyway.

Regards,

Stefan

[Former Member]

Please let us know the results!

[Former Member]

Hi all,

SAP has confirmed that this a software error. Somehow the ICM munches up the .zip-file while processing the request. I'm hoping to have a solution soon...

Regards,

Stefan

[former_member181879]

Stefan,

I did a lot of the analysis work on your OSS message earlier in the week. My current feeling is that it has to do with one HTTP header that is changed during compression sequence. We must wait for a colleage to help with some parts of the code that runs in the kernel where we suspect the problem is. But this will only be next week.

brian

[former_member181879]

Today I was asked to quickly test a new patch kernel containing a fix for the problem that you described. It worked perfectly. So I expect that you OSS problem will be updated in the new few days with information about when the new kernel will become available. (As far as I know, new kernels are only released every four weeks, so it still might take some time after a validation phase.)

The problem had to do with the fact that a ZIP file is zipped once more. It seems that in some cases this confused the browser, and the gzipped content was saved. The fix now reduces to not using zip on outgoing zipped content.

Which made we remember again note 715598 (Global deactivation of GZIP compression for HTTP). There is a (relatively new) profile parameter with which you can completely disable gzip compression in the kernel for all HTTP connections. This should be an easy way to workaround this problem at the moment.

[Former Member]

Brian,

this sounds good and hopefully we don't have to wait too long for the new kernel.

I know the note you mention, but since we are using the compression for other pages, I don't think it will be possible for us to deactivate it globally.

This leaves us in the hands of SAP, waiting for the kernel... )

Thanks,

Stefan

[former_member181879]

We have to very carefully distinguish between something that is a K.O. createria for your work, versus a small workaround that just makes it temporarily slower. Please do not just go into waiting mode with a complete stop in your business. It takes a few weeks to build a new patched kernel, as there are many regression tests that must be done (over all platforms), etc. This is why I have gone the extra mile already long time to ask for that global switch and now to again to look it up for you. This will definitely help you to continue working, maybe just at a slightly higher latency (and cost of bandwidth if this plays a role). I see no technical reasons why you can not activate that profile switch immediately and to remove it at the next kernel update.

[Former Member]

Have you searched the OSS for this issue? Perhaps you've found a bug.

If you get no further responses today and you don't find anything in the OSS then perahsp you should open an OSS ticket and let them know about the problem.

Edit by Craig:

Be sure to search the OSS first.

Maybe this note will help 763557

Message was edited by: Craig Cmehil