2012-11-21 6 views
18

Próbuję użyć funkcji zwijania, aby przesłać zbiorczo do serwisu YouTube, zgodnie ze specyfikacją interfejsu API here; krótko mówiąc, wymaga wieloczęściowego żądania POST z metadanymi w formacie XML i Content-Type z application/atom+xml; charset=UTF-8, a następnie same dane wideo.zawinięcie: typ zawartości pliku dla wieloczęściowego testu POST (interfejs API serwisu YouTube)

Mój obecny wiersz poleceń (pobieranie metadanych z upl.xml i wideo z upl.mkv) wygląda mniej więcej tak:

curl -s -F "[email protected]" -F "[email protected]" -H 'GData-Version: 2' -H 'Authorization: GoogleLogin auth=<AUTH>' -H 'Slug: upl.mkv' -H 'X-GData-Key: key=<KEY>' http://uploads.gdata.youtube.com/feeds/api/users/default/uploads 

Kiedy sprawdzić rzeczywisty wniosek, który jest wysyłany z --trace, to wygląda tak, jakby oba pliki były wysyłane we właściwej kolejności, ale typ zawartości metadanych jest ustawiony na application/octet-stream; Przesyłanie kończy się zgodnie z oczekiwaniami, ale YouTube odmawia przetworzenia wideo.

Gdy próbuję złożyć upl.xml z --data, --data-ascii, --form-string itd. I po prostu asortyment innych błędów, które pozwala mi wierzyć, że to w dół do nieprawidłowego Content-Type. Jeśli zignoruję metadane i po prostu wyślę plik wideo, to działa dobrze, ale niestety to nie rozwiązuje mojego problemu.

Czy brakuje mi tu czegoś, a jeśli nie, to można to zrobić bez naruszania libcurl?

Odpowiedz

26

Po pierwsze, możesz określić typ zawartości dla przesyłanej części, dodając "; type = magic/string". Jak na przykład w danym przypadku wideo:

curl -F "[email protected]; type = wideo/MPEG4" [URL]

(użycie --trace lub --trace- ascii, aby sprawdzić, czy curl wysyła dokładnie to, co chcesz)

... ale to powiedziawszy, domyślam się, że jest bardzo mało prawdopodobne, że serwer odbierający faktycznie dba o to, co klient twierdzi, że typ zawartości jest. To znaczy, myślę, że źródłem twojego problemu nie jest wcale rodzaj treści.

Powiązane problemy