[SOAP] file request

Pagina: 1
Acties:

Onderwerpen


  • nota
  • Registratie: Augustus 2001
  • Laatst online: 12-08 08:52
Via mijn webservice o.b.v. REST kan ik bestanden opvragen ( via GET request: ../download/{documentId} ). Deze bestanden zijn niet publiek toegankelijk (webservice werkt met basic-auth) en er wordt dan ook geen filepath/url in de response teruggegeven maar het werkelijke document wordt in de html body teruggegeven. Nu kunnen dit natuurlijk bestanden van ieder willekeurig type zijn. Ik wil bij het opvragen van het document kunnen bepalen welke extensie ik aan het document moet geven zodat ik hem in de juiste vorm op een andere fileserver kan zetten (en mogelijk ook de originele bestandsnaam, maar dit is niet perse nodig). Ik heb geen idee waar ik deze informatie het beste kan neerzetten in de response: ik zat te denken aan de header context-type of een custom parameter in de header. De body kan natuurlijk ook, normaal gesproken geef ik daarin een json result terug maar bij dit type request dus alleen de filecontent.

Kan iemand mij aangeven wat hierbij de meest voor de hand liggende wijze zou zijn?

[ Voor 0% gewijzigd door nota op 16-02-2012 11:42 . Reden: geen SOAP maar REST (titel is ook niet juist) ]

If you think sex is a pain in the ass, try different position


  • Voutloos
  • Registratie: Januari 2002
  • Niet online
Soap heeft dus helemaal niets te maken met wat jij aan t doen bent. Je had net zo goed een [schaapjes] of [wasknijpers] tag in je topictitel kunnen zetten. 8)7

Je bent op zoek naar de Content-Type en Content-Disposition http response headers. ;)

[ Voor 21% gewijzigd door Voutloos op 16-02-2012 11:49 ]

{signature}


  • nota
  • Registratie: Augustus 2001
  • Laatst online: 12-08 08:52
Voutloos schreef op donderdag 16 februari 2012 @ 11:47:
Soap heeft dus helemaal niets te maken met wat jij aan t doen bent. Je had net zo goed een [schaapjes] of [wasknijpers] tag in je topictitel kunnen zetten. 8)7

Je bent op zoek naar de Content-Type en Content-Disposition http response headers. ;)
Klopt inderdaad, titel is niet juist, ik was even in de war met een andere webservice. Content-type kende ik al, content-disposition niet. Met content-disposition kan ik volgens mij bereiken wat ik wil:

code:
1
Content-Disposition: attachment; filename=dit_is_een_afbeelding.jpeg;


Content-type moet ik dan neem ik aan zetten obv de extensie, als ik deze tenminste herken.

If you think sex is a pain in the ass, try different position


  • HyperioN
  • Registratie: April 2003
  • Laatst online: 24-05 15:42
Volgens mij heeft Content-Disposition hier eigenlijk niks mee te maken.
Met de Content-Disposition-header kun je het standaard-gedrag van een browser "overrulen" met betrekking wat hij met de file doet.
Default is de content-disposition inline; dat wil zeggen dat een browser bijvoorbeeld een .jpg toont in de browser; en een .mp3 zal afspelen als daarvoor een player geïnstalleerd is.
Wanneer je echter Content-Disposition: attachment; als header meegeeft, zal de browser altijd het bestand willen opslaan en een "Bestand opslaan als"-dialoogvenster weergeven.
Zie Wikipedia: MIME

Omdat jij zo te zien echter bestanden wilt opvragen/inlezen en ergens anders wil wegschrijven, komt de browser/user amper aan te pas.
Volgens mij heb je dus aan content-type voldoende.
Of ik begrijp je verkeerd ;)

  • nota
  • Registratie: Augustus 2001
  • Laatst online: 12-08 08:52
HyperioN schreef op donderdag 16 februari 2012 @ 12:09:
Volgens mij heeft Content-Disposition hier eigenlijk niks mee te maken.
Met de Content-Disposition-header kun je het standaard-gedrag van een browser "overrulen" met betrekking wat hij met de file doet.
Default is de content-disposition inline; dat wil zeggen dat een browser bijvoorbeeld een .jpg toont in de browser; en een .mp3 zal afspelen als daarvoor een player geïnstalleerd is.
Wanneer je echter Content-Disposition: attachment; als header meegeeft, zal de browser altijd het bestand willen opslaan en een "Bestand opslaan als"-dialoogvenster weergeven.
Zie Wikipedia: MIME

Omdat jij zo te zien echter bestanden wilt opvragen/inlezen en ergens anders wil wegschrijven, komt de browser/user amper aan te pas.
Volgens mij heb je dus aan content-type voldoende.
Of ik begrijp je verkeerd ;)
De workflow is als volgt:

1. ik toon de user een lijst met zijn bestanden (via een ander rest request)
2. user klikt 1 van de bestanden aan.
3. ik stuur een request naar de webservice server en vraag het bestand op.
4. ik zet hem op de eigen fileserver.
5. ik wil dit bestand terug aan de user geven.

Voor punt 5 moet ik dan wel weten wat voor bestand het is (content-type) maar ook wat de extensie was (onderdeel van content-disposition). Alleen met het content-type ben ik er volgens mij niet. Het kan zomaar een onbekend bestand zijn (bijvoorbeeld onbekend.dat). Als de content-disposition hier niet voor bedoeld is dan moet ik het natuurlijk niet zo doen.

If you think sex is a pain in the ass, try different position


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 09-09 16:17

Janoz

Moderator Devschuur®

!litemod

Zou je die workflow nog even wat nader kunnen toelichten en daarbij ook even de verschillende computers (clients en/of servers) aan kunnen geven? Klopt het dat er 4 partijen zijn? Een client applicatie! (1) welke soap berichten naar je server(2) stuurt die vervolgens een bestand van de ene server(3) op een andere server(4) zet welke vervolgens vanaf die server weer naar de client gestuurd wordt?

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • nota
  • Registratie: Augustus 2001
  • Laatst online: 12-08 08:52
Janoz schreef op donderdag 16 februari 2012 @ 12:22:
Zou je die workflow nog even wat nader kunnen toelichten en daarbij ook even de verschillende computers (clients en/of servers) aan kunnen geven? Klopt het dat er 4 partijen zijn? Een client applicatie! (1) welke soap berichten naar je server(2) stuurt die vervolgens een bestand van de ene server(3) op een andere server(4) zet welke vervolgens vanaf die server weer naar de client gestuurd wordt?
4 en 2 zijn dezelfde, dus:

user -> server 1 (web request)
server 1 -> server 2 (rest request)
server 2 -> server 1 (rest response)
server 1 -> server 1 (verwerk bestand, en plaats op server 1)
server 1 -> user (geef bestand terug)

If you think sex is a pain in the ass, try different position

Pagina: 1