AJAX로 파일 업로드가 되나요?

제 생각에는 업로드는 post로 하면서 업로드 진행 상황을 xmlhttprequest로 알아온다는 것 같군요.

http://mir.aculo.us/articles/2005/04/10/upload-progress-with-ruby-on-rails-and-ajax-demo-movie

일반적인 방법은 아니군요. 그런데 혹시 직접 해보셨나요?
var ado = new ActiveXObject('ADODB.Stream');
이 부분에서부러 에러가 발생하던데...

브라우저의 보안모델을 완전히 위배하는 것이라 "그냥" 될 것 같지는 않아서요..

그리고 ditto님이 올려주신 내용은 ajax로 실제 파일을 업로드하는게 아니라 진행상황만 볼 수 있는 것이라서 서로 다른 내용인듯합니다.

ruby라고 해서 특별한 뭔가가 있어서 가능한건 아닙니다
다만 ajax랑 관련해서 루비가 좀 지원이 잘되는걸로 알고 있고요
php로도 유사한 트윅이 발표된 적이 있었죠 (그땐 ajax를 이용한건 아니었고 php소스에 약간의 패치를 가하는거였습니다 클릭)
여튼 ruby에서 가능하다면 php로도 가능하다는게 요점이고요
서버측에서 업로드중인 파일의 정보를 주기적으로 읽어서 웹페이지에 동적으로 보여주는게 기본적인 컨셉이겠네요.

정확한 정보 감사합니다 :)

IE는 에러메세지가 정말 멍청한것 같습니다. 특히 한글은요.. 한글 에러 메세지로는 구글링도 안되고.....

위에 링크된 문서에는 ActiveX component can’t create object: ‘ADODB.Stream’ 라는 정확한 에러메세지가 나오는 걸로 되어있는데 한글IE에서는 "자동화 서버는 개체를 작성할 수 없습니다" 라고 나오네요. 사오정인지 원.....

그나저나 작년 12월 이전에는 그냥 쓸 수 있었다니 대단한 일이네요.

아무래도 PHP는 소스 코드에 패치를 해야 가능할 것으로 보입니다.
Ruby on Rails는 Webrick이라는 자체 웹 서버를 사용하기 때문에 (cgi, fastcgi등도 사용할 수 있지만) 업로드 관련 처리를 해주는 듯 합니다.

제가 위에 링크한 phpschool 의 글을 보시면 php소스를 직접 수정한걸로 내용이 나옵니다.

그리고 이곳을 보면 위에 링크해주신 ROR의 upload progress 예제는 webrick 을 이용한게 아니라 apache1/2 or libhttpd1.4를 이용한걸로 나오네요. fastcgi 방식으로 설정을 했는데, 더 자세히 보지는 않았습니다만 ActionController::Base.enable_upload_progress 이런 내용이 나오는걸로 봐서 ROR 프레임웍 차원에서 뭔가를 지원해주는군요. (이쯤에서 nohmad님이 나타나셔서 설명을 해주시면 좋을텐데...)

파일업로드는 안되는 것으로 알고 있습니다.
보안상의 이유로 이런저런 제약이 많은 편이라 자바스크립트만으로는 힘들 것 같습니다.

ROR의 파일업로드 진행바도 대충 보긴 했지만, iframe 을 이용하는 것 같습니다.
제가 본 바로는 ROR은 실제로는 코드를 생성해주고 CGI를 실행하는 정도의 모듈 역할을 하는 것 같던데 자세히 본 것은 아니라서 정확히 말씀드리기는 뭐합니다.

ROR의 Upload progressbar 와 비슷한 원리로 구현한 프로젝트는 예전에 본 적이 있습니다.
http://sourceforge.net/projects/megaupload

AJAX를 쓰지는 않았지만 파일업로드에 따라서 진행상황을 refresh 하는 방식은 비슷합니다.

헛.. 이런 쓰레드가 있었군요? -_-;

제가 해보지는 않았지만, AJAX로 파일업로드 됩니다. 단지 multipart/form-data로 인코딩된 form을 제출하면 됩니다.

파일업로드 진행률 구현에 관해서는 클라이언트와 서버를 분리해서 생각해야 합니다.

먼저 클라이언트 입장에서 파일업로드 진행률 구현은 단순히 polling 메커니즘을 이용하는 것에 불과합니다. 서버에 수초 간격으로 계속 요청을 보내서 진행률을 얻습니다. Google Suggest도 그러하지만 상당한 낭비라고 생각할 수도 있습니다. HTTP가 원래 좀 그렇죠. ;-)

서버에서는 1) 실제 파일업로드를 처리하는 서비스(file-upload.cgi)와 2) 단순히 진행률을 알려주는 서비스(progress-notify.cgi) 2가지를 모두 제공해야 합니다.

file-upload.cgi는 RFC1867, 2388 등을 참고하여 multipart/form-data로 인코딩된 사용자의 파일업로드 요청을 적당히 파싱하여 원하는 작업을 합니다. 그런데 multipart로 파싱하기 전에 HTTP 요청 스트림 자체를 하나의 임시파일로 만들어서 저장한다고 생각해봅시다. 모든 HTTP POST 요청은 길이 정보를 헤더에 넣어야 하기 때문에 클라이언트가 업로드하려는 전체 파일 목록을 다 받아보지 않고도 요청의 길이를 계산할 수 있습니다. header와 boundary, 그외 부가적인 폼 내용까지 모두 합한 크기이긴 하지만, 어차피 파일별 진행률을 알려는 것이 아니라 전체 요청의 진행률을 알기 위한 것이므로 무시해도 크게 상관없을 것입니다. 임시파일을 만들 때 truncate(2)을 이용해서 미리 스트림 크기 만큼의 파일을 만들어 둡니다.

progress-notify.cgi는 file-upload.cgi가 생성한 서버측 임시파일의 경로를 알고 있어야 합니다. 클라이언트쪽에 적당한 키를 만들어 공유하면 될 것 같습니다. file-upload.cgi는 클라이언트가 파일업로드를 진행할 때 적당한 버퍼를 가지고 progress-notify.cgi가 알고 있는 파일에다 쓰려고 할 것입니다. progress-notify.cgi는 그 임시파일을 읽기 전용으로 열어서 fstat(2)이나 ftell(3)을 하면 현재 얼마만큼 write(2) 하고 있는지 알 수 있고, 이것을 클라이언트에 응답하면 됩니다.

간단한 테스트 세션입니다.

$ cat file-upload.cgi
#!/usr/bin/ruby
puts "Content-Type: text/html\n\n"
puts ARGF.read

$ cat file.1 file.2
content of file.1
content of file.2

$ curl -v -F 'file1=@file.1' -F 'file2=@file.2' -F 'another=form_element' http://nohmad.sub-port.net/file-upload.cgi
* About to connect() to nohmad.sub-port.net port 80
*   Trying 211.174.177.198... * connected
* Connected to nohmad.sub-port.net (211.174.177.198) port 80
> POST /file-upload.cgi HTTP/1.1
User-Agent: curl/7.13.2 (i686-pc-linux-gnu) libcurl/7.13.2 OpenSSL/0.9.7e zlib/1.2.3
Host: nohmad.sub-port.net
Pragma: no-cache
Accept: */*
Content-Length: 496
Expect: 100-continue
Content-Type: multipart/form-data; boundary=----------------------------834bb4530f38

< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< Date: Tue, 16 Aug 2005 18:37:54 GMT
< Server: Apache
< Transfer-Encoding: chunked
< Content-Type: text/html
------------------------------834bb4530f38
Content-Disposition: form-data; name="file1"; filename="file.1"
Content-Type: application/octet-stream

content of file.1

------------------------------834bb4530f38
Content-Disposition: form-data; name="file2"; filename="file.2"
Content-Type: application/octet-stream

content of file.2

------------------------------834bb4530f38
Content-Disposition: form-data; name="another"

form_element
------------------------------834bb4530f38--
* Connection #0 to host nohmad.sub-port.net left intact
* Closing connection #0

PHP도 $HTTP_RAW_POST_DATA를 통해 파싱되기 전의 클라이언트의 요청 스트림 전체를 구할 수 있는 걸로 알고 있습니다.

토론이
(1) 파일 업로드가 가능한가
(2) 파일 업로드 진행상태를 표시할 수 있는가
이렇게 2가지로 섞여있는 것 같습니다.

(1) 파일 업로드 자체는 불가능한 것 같습니다.
지난주에 이 글을 볼 때쯤, 마침 전 '파일을 여러개 업로드할때 파일을 직렬화해서 AJAX로 처리하면 어떨까' 또는 'IFRAME 쪽으로 파일을 하나씩 떠넘겨서 form.submit()할 수는 없을까' 궁리하고 있었는데요.
혹시나 하는 기대를 품고 삽질을 했으나, 역시나 자바스크립트가 파일을 억세스할 수 없다는 보안문제는 넘어갈 수 없더군요.

(2) 업로드 진행상태를 표시하는건, 위에서 말씀하신대로 PHP 패치라든가 lighttpd의 모듈 등을 이용해서 AJAX로 가능한데요.

토론에 덧붙여, 웹서버와 PHP/CGI가 어떻게 파일을 받아서 처리하는지가 궁금합니다.
웹서버에서 파일을 전부 다 받은 다음 PHP/CGI로 넘겨주는줄 알았는데, 가만 보니 파일이 업로드되는 도중에 이미 제어권은 PHP/CGI쪽으로 넘어가는 것 같군요.
특히 대용량 파일을 업로드할때가 문제가 될 수 있을 것 같아서요. 서버쪽에서 이것을 파일스트림 핸들로 처리하지 않고 파일을 통째로 메모리에 담아둔다면 심각한 문제가 생기지 않나 싶어요.

웹에서 파일을 업로드하는 방법은 enctype이 multipart/form-data인 폼을 post하는 것 뿐입니다.
PUT메소드가 있지만 이를 지원하는 브라우져는 못 본거 같습니다.(직접 HTTP클라이언트를 만들고 PUT메소드를 사용해서 파일을 전송하니 대부분의 웹서버가 받아주더군요^^)

문제는 post가 진행중인 커넥션에 대해서 무언가 응답을 날리면(여기서는 업로드 진행상황이겠죠) 그 커넥션에서 진행중이던 post가 중단된다는 것입니다.
그래서 iframe이건 frame이건 혹은 popup창을 열고 그 커넥션을 이용하는 것은 post중인 커넥션이 아닌 새로운 커넥션이 필요하기 때문이죠.

php를 패치하고 말고의 여부는 이 동작과는 무관하다고 추측(!)됩니다.
이것은 HTTP프로토콜상의 문제이지 서버측 혹은 클라이언트 측의 문제가 아니니까요.

그리고, 업로드 중에 상태바 갱신 만의 문제라면 별도의 창(또는 frame 또는 iframe)과 서버푸시(또는 클라이언트풀)을 이용하면 AJAX없이도 충분히 가능합니다만 "뽀대"와 효율성의 문제겠지요.

결국은 클라이언트와 서버간에 업로드되는 파일의 임시 파일명을 공유하는게 핵심적인 부분인데 지금까지 언급된 방법들은 모두 cgi 를 통해서 해결을 하고 있군요..

ㅎㅎ 그런데 업로드 진행을 보여주는거야 UI의 문제니까 뽀대가 중요하지 않을까요 8)

스패머의 압뷁..
덕분에 이 글이 간만에 위로 올랐군요.

php로 테스트 해본 결과, 일단 파일 업로드 중이면 제어권은 웹서버가 쥐고 있는 상태가 되므로 /tmp 의 업로드 중인 파일 크기를 검사해서 표시한다던가는 불가능 했습니다. 단 새 창을 띄우던지 해서 거기서 리프레시를 하던 서버 푸시를 쓰던 업로드되고 있는 파일 크기를 검사한다면 실시간 표시를 할 수 있을지도 모르겠습니다. ...그런데 그렇게까지 해서 서버에 무리를 주는 것 치고 얻는 게 너무 적죠? 결국 구현을 해도 별 이득이 없다는 결론입니다.

전에 ajax와 리프레시를 응용해서 php 소스 수정 안하고도 실시간 업로딩 표시를 하는 걸 본 적이 있는데... 소스 크기가 상당히 방대하더군요. 이상한 것들 잡다하게 다 섞여서 돌아가던데 분석 포기 했습니다. 게다가 동작 모습도 상당히 불안했고 무엇보다도 그렇게까지 해서라도 스크립트에서 실시간 표시해야 할 이유가 없어보였습니다. 배보다 배꼽이 큰 상황.

대신 플래시를 쓴다면 실시간 표시는 더 싼 비용으로 가능합니다. 차라리 이쪽을 배워서 쓰는게 나을 듯 싶네요. 업로딩 바도 이쪽이 더 뽀대(?)가 나겠죠. -_-