headers
М.А. Мохначевский | 1 Nov 03:06

У меня проблема с upload

Всем привет!
Эта тема должно быть поднималось много раз. Извините
что беспокою опять, 
просто я не нашел решения.
Суть проблемы:
Поставил nginx-0.6.31 как front-end к Apache httpd 2.0 на котором
крутится 
ClipShare (в общем клон YouTube) с аплоадом через Uber Uploader. 
Если бы просто progress bar не показывался, мог бы и
смириться с этим. Но я не 
смог сделать так, чтобы видео заливалось. Сам ClipShare
говорит, что видео 
залилось, но flv файл не появляется в /flvideo/ (Без nginx все
прекрасно 
работает). 
Если кто может поделиться рабочим конфигом на эту
тему, буду бесконечно 
признателен. Буду рад даже ссылке по теме)
Заранее спасибо.
Permalink | Reply | 4 comments |
headers
Асафов Сергей aka MurZiK | 1 Nov 04:27
Picon

Re: У меня проблема с upload

А у nginx права писать в ту папку есть?Юзер одинаковый с апачем?
----- Original Message ----- 
From: "М.А. Мохначевский" <tetsio@...>
To: <nginx-ru@...>
Sent: Saturday, November 01, 2008 5:06 AM
Subject: У меня проблема с upload

> Всем привет!
> Эта тема должно быть поднималось много раз. Извините
что беспокою опять,
> просто я не нашел решения.
> Суть проблемы:
> Поставил nginx-0.6.31 как front-end к Apache httpd 2.0 на котором крутится
> ClipShare (в общем клон YouTube) с аплоадом через Uber Uploader.
> Если бы просто progress bar не показывался, мог бы и
смириться с этим. Но 
> я не
> смог сделать так, чтобы видео заливалось. Сам ClipShare
говорит, что видео
> залилось, но flv файл не появляется в /flvideo/ (Без nginx все прекрасно
> работает).
> Если кто может поделиться рабочим конфигом на эту
тему, буду бесконечно
> признателен. Буду рад даже ссылке по теме)
> Заранее спасибо.
>
Permalink | Reply | 2 comments |
headers
М.А. Мохначевский | 1 Nov 05:04

Re: У меня проблема с upload

On Saturday 01 November 2008 12:27:28 Асафов Сергей aka MurZiK wrote:
> А у nginx права писать в ту папку есть?Юзер одинаковый с апачем?

с апачем юзера разные. PHP исполняется из под suphp. CGI из
под того юзера же.
Но мне надо бы, чтобы аплоадом занимался не nginx, а CGI
скрипт)
Permalink | Reply | 1 comment |
headers
Alexey Kovyrin | 1 Nov 06:35
Favicon
Gravatar

Re: У меня проблема с upload

Ох уже эти "клоны" ютуба... Делают все, кому не лень...

По теме: товарищ, тут не водятся экстрасенсы - раз уж
взялись за такую
великую задачу, как клонирование ютуба, то научитесь
читать логи и
отлаживать всю построенную вами цепочку сервисов -
это очень поможет в
будущем. Говорю как автор одного из клонов :-)

1) Аплоад приходит в нгинкс? (смотреть логи нгинкса в дебаг-моде)
2) Аплоад сохраняется во временный каталог? (смотреть
те же логи)
3) Передается ли он бекенду? (угу, правильно, там же)
4) Передает ли бекенд аплоад скрипту? (смотреть логи
бекенда (апача?))
5) Получает ли скрипт аплоады? (смотреть в логи
скрипта. Да! забыл
сказать - они тоже очень нужны будут, потому добавьте
если нету)

Когда будут ответы на все 5 вопросов (все!), велкам бек в
мыллист за
решением проблемы (если она не будет решена к тому же моменту).

2008/11/1 М.А. Мохначевский <tetsio <at> yaknet.com>:
> On Saturday 01 November 2008 12:27:28 Асафов Сергей aka MurZiK wrote:
>> А у nginx права писать в ту папку есть?Юзер одинаковый с апачем?
>
> с апачем юзера разные. PHP исполняется из под suphp. CGI из
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrey N. Oktyabrski | 1 Nov 07:44
Picon

Re: server_name bug

Dmitriy MiksIr wrote:
>>> Тут проблема не в nginx'e, пишите в списки рассылки
ядрер linux,
>>> freebsd чтобы меняли логику сокетов - если
прослушивается 0.0.0.0 и
>>> 1.2.3.4, все запросы пришедшие на 1.2.3.4 все равно
направлять на
>>> 0.0.0.0.
>> Как раз для сокетов это очень правильное поведение.
А для HTTP - 
>> нелогично.
> 
> Почему же?
> Если есть два сервера
> server_name *.domain.ru
> и
> server_name old.domain.ru
> описанных именно в этом порядке
> и запрос приходит на old.domain.ru - в каком сервере логично
этот запрос 
> отработать?
Не надо выдёргивать фразы из контекста. Если есть
такие server_name и 
запрос приедет на адрес, явно прописанный в listen для
*.domain.ru c 
Host: old.domain.ru, nginx отправит его в первый server, не глядя на 
server_name вообще, если old.domain.ru висит на *:80. То есть, выбор 
хоста по адресу (по логике сокетов) сейчас имеет
приоритет над выбором 
хоста по имени.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Andrew Kopeyko | 1 Nov 08:00
Picon
Favicon
Gravatar

Re: Проблема в NGINX

On Fri, 31 Oct 2008, Alex Tutubalin wrote:

>
>> игнорировать. А вот выдавать 1.1 в ответ на 1.0 запрос вы
права не
>> имеете - на это есть вполне прямой запрет.
>
> Да ладно, все выдают, бэкенду тоже можно.
> lexa <at> home-gw:~# telnet www.rambler.ru 80
> Trying 81.19.70.1...
> Connected to www.rambler.ru.
> HEAD / HTTP/1.0
>
> HTTP/1.1 200 OK
   ^^^^^^^^
Этим сервер обозначает максимальную версию
протокола, который он 
поддерживает.

Предполагалось, что последующие запросы клиент
может делать уже по версии 
HTTP/1.1.

Но сам этот ответ - версии HTTP/1.0

> Server: nginx/0.7.20
>
> Другой вопрос, что выдавать Chunked наверное не стоит.
Хотя в RFC2616 про
> это место довольно смутно написано.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alex Tutubalin | 1 Nov 10:06
Picon
Favicon

Re: Проблема в NGINX


> >HTTP/1.1 200 OK
>   ^^^^^^^^
> Этим сервер обозначает максимальную версию
протокола, который он 
> поддерживает.
> 
> Предполагалось, что последующие запросы клиент
может делать уже по версии 
> HTTP/1.1.
> 
> Но сам этот ответ - версии HTTP/1.0

Скажи пожалуйста, а как из данного респонза следует,
что ответ версии 1.0,
а не, например, 0.9 или 1.145?

Казалось бы, что в status line написано, такая и версия.....

Алексей Тутубалин
mailto: lexa@...
Web: http://www.lexa.ru/lexa
Permalink | Reply | 3 comments |
headers
Alex Tutubalin | 1 Nov 10:04
Picon
Favicon

Re: Проблема в NGINX

> > 
> > Другой вопрос, что выдавать Chunked наверное не стоит.
Хотя в RFC2616 про
> > это место довольно смутно написано.
> 
> Э... "довольно смутно"?
> 
> A server MUST NOT send transfer-codings to an HTTP/1.0 client.

Ну вот я бы ожидал увидеть эту фразу в разделе Compatibility.

Я вот вчера посмотрел на этот RFC c точки зрения
имплементатора и ужаснулся.

Алексей Тутубалин
mailto: lexa@...
Web: http://www.lexa.ru/lexa
Permalink | Reply | 0 comments |
headers
Andrew Kopeyko | 1 Nov 10:25
Picon
Favicon
Gravatar

Re: Проблема в NGINX

On Sat, 1 Nov 2008, Alex Tutubalin wrote:

>
>>> HTTP/1.1 200 OK
>>   ^^^^^^^^
>> Этим сервер обозначает максимальную версию
протокола, который он
>> поддерживает.
>>
>> Предполагалось, что последующие запросы клиент
может делать уже по версии
>> HTTP/1.1.
>>
>> Но сам этот ответ - версии HTTP/1.0
>
> Скажи пожалуйста, а как из данного респонза следует,
что ответ версии 1.0,
> а не, например, 0.9 или 1.145?

Версия ответа задаётся клиентом - он попросил 1.0, он
его и получил.
Не "0.9" - патамучта заголовки получил.
И не "1.145" - потому что прямо запрещено отвечать бОльшей версией.

> Казалось бы, что в status line написано, такая и версия.....

Перед написанием того ответа я пролистал rfc - но не
нашёл того места где 
это описывается. Но было такое - помню точно. Иначе
нельзя было бы
(Continue reading)

Permalink | Reply | 2 comments |
headers
Roxis | 1 Nov 10:33
X-Face
Picon
Favicon

Re: Проблема в NGINX

On Saturday 01 November 2008, Andrew Kopeyko wrote:
> Перед написанием того ответа я пролистал rfc - но не
нашёл того места где
> это описывается. Но было такое - помню точно. Иначе
нельзя было бы
> говорить "HTTP/1.1 200 OK" в ответ на "HTTP/1.0"-запрос...

RFC2145 - Use and Interpretation of HTTP Version Numbers
Permalink | Reply | 1 comment |

Gmane