*http

посоны, тут такая тема, хуярю я access log поверх библиотеки HttpCore. возник такой вопрос, что считать временем обработки запроса, а точнее, когда считать, что обработка началась? после получения заголовков или после получения тела (если я не поточно его обрабатываю)?

#tisoge

1 comment

в связи с #tiognh разыскивается аналог nginx, такой же распиздатый, но с блекджеком и шлюхами^W^W^W динамически загружаемыми библиотеками и тредами.
inb4: mongoose, lig httpd, apache http server, tomcat, glassfish

#tiogns

add comment

подумалось тут. а ведь хороший, годный асинхронный http-сервер при вычитывании запроса до появления CRLF CRLF всё равно будет все CRLF'ы находить. так что мог бы сразу складывать в какой-нибудь отдельный массив разметку заголовков.

#tfnnhz

8 comments

кто-нибудь писал HTTP-сервера с кастомной логикой как плагин к nginx? какие подводные камни кроме того, что я, вероятнее всего, заебусь?

#tfgisz

2 comments

Немного фактов:
1. rfc2616 определяет Request-Line как «Method SP Request-URI SP HTTP-Version CRLF»
2. Request-URI, в свою очередь, стало быть определяется как «"*" | absoluteURI | abs_path | authority»
3. Собственно всё. В соответствии с rfc2616 самый обычный Request-Line «GET /path?query HTTP/1.1\r\n» является ... more →

#tfogit

6 comments

Часть первая: полезная.
Всем желающим писать хттп-сервер на жабке и кому не подходит HttpCore вовсе не
обязательно костылить свой велосипед. Оказывается начиная с JDK 1.6 уже есть
простой и понятный сервер:
http://docs.oracle.com/javase/7/docs/api...
Не умеет только давать возможность вешать ... more →

#tfzitt

4 comments

Если вы уже начали поточно отдавать файл по HTTP в chunked endcoding, но
вспомнили, что нужно сообщить ещё что-то очень важное, что не является частью
тела ответа, то после нулевого чанка просто допишите нужный заголовок, вместо
того чтобы ставить завершающий CRLF. Хорошо бы ещё в начале пакета, в ... more →

#totthn

add comment

я, конечно, всех уже заебал, но тем не менее.
1. Сразу скажу почему не использую новомодные multiplexing и NIO. Использую, но
для другого. В случае же, когда нужно обрабатывать большое количество данных
отсылаемых POST'ом и отвечать просто 200 или 400 (или 50x) рекомендуют
использовать старый добрый accept() и ... more →

#tzoint

1 comment

в поисках очередного шквала критики, пишу сюда, что пока пришёл к следующему варианту организации обработки запросов.
- Используется всё тот же ThreadPoolExecutor(workers, ..., new ArrayBlockingQueue<Runnable>(connections — workers))
- После завершения обработки очередного запроса, в случае, если коннекшн ещё жив, ... more →

#tzozhh

add comment

я тут пытаюсь понять, как правильный HTTP-сервер должен себя вести. хочется услышать критику к подходам и методам.
рассуждаю в терминах жабы, но все кто осилил http://docs.oracle.com/javase/7/docs/api тоже приглашаются к дискуссии.

- Когда пишешь http-сервер первый раз, то на каждый accept() создаёшь новый
Thread ... more →

#tzzngg

8 comments

жуйк, а каково твоё мнение, количество соединений к серверу, и количество обрабатывающих их потоков, должны совпадать?

#tzzngi

5 comments

Псач, есть один HTTP-ответ, длины которого я заранее не знаю, поэтому Content-Length я не выставляю, а Chunk Encoding писать западло. Так вот, насколько корректно просто послать FIN в конце передаваемых данных?

#onnthi

2 comments