hirthwork
27.01.2013 10:25
посоны, тут такая тема, хуярю я access log поверх библиотеки HttpCore. возник такой вопрос, что считать временем обработки запроса, а точнее, когда считать, что обработка началась? после получения заголовков или после получения тела (если я не поточно его обрабатываю)?
hirthwork
08.01.2013 15:08
в связи с #tiognh разыскивается аналог nginx, такой же распиздатый, но с блекджеком и шлюхами^W^W^W динамически загружаемыми библиотеками и тредами.
inb4: mongoose, lig httpd, apache http server, tomcat, glassfish
hirthwork
30.12.2012 21:04
подумалось тут. а ведь хороший, годный асинхронный http-сервер при вычитывании запроса до появления CRLF CRLF всё равно будет все CRLF'ы находить. так что мог бы сразу складывать в какой-нибудь отдельный массив разметку заголовков.
hirthwork
24.12.2012 15:24
кто-нибудь писал HTTP-сервера с кастомной логикой как плагин к nginx? какие подводные камни кроме того, что я, вероятнее всего, заебусь?
hirthwork
29.11.2012 20:54
Немного фактов:
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 →
hirthwork
25.11.2012 19:23
Часть первая: полезная.
Всем желающим писать хттп-сервер на жабке и кому не подходит HttpCore вовсе не
обязательно костылить свой велосипед. Оказывается начиная с JDK 1.6 уже есть
простой и понятный сервер:
http://docs.oracle.com/javase/7/docs/api...
Не умеет только давать возможность вешать ... more →
hirthwork
21.08.2012 17:02
Если вы уже начали поточно отдавать файл по HTTP в chunked endcoding, но
вспомнили, что нужно сообщить ещё что-то очень важное, что не является частью
тела ответа, то после нулевого чанка просто допишите нужный заголовок, вместо
того чтобы ставить завершающий CRLF. Хорошо бы ещё в начале пакета, в ... more →
hirthwork
10.07.2012 19:32
я, конечно, всех уже заебал, но тем не менее.
1. Сразу скажу почему не использую новомодные multiplexing и NIO. Использую, но
для другого. В случае же, когда нужно обрабатывать большое количество данных
отсылаемых POST'ом и отвечать просто 200 или 400 (или 50x) рекомендуют
использовать старый добрый accept() и ... more →
hirthwork
08.07.2012 20:07
в поисках очередного шквала критики, пишу сюда, что пока пришёл к следующему варианту организации обработки запросов.
- Используется всё тот же ThreadPoolExecutor(workers, ..., new ArrayBlockingQueue<Runnable>(connections — workers))
- После завершения обработки очередного запроса, в случае, если коннекшн ещё жив, ... more →
hirthwork
08.07.2012 17:34
я тут пытаюсь понять, как правильный HTTP-сервер должен себя вести. хочется услышать критику к подходам и методам.
рассуждаю в терминах жабы, но все кто осилил http://docs.oracle.com/javase/7/docs/api тоже приглашаются к дискуссии.
- Когда пишешь http-сервер первый раз, то на каждый accept() создаёшь новый
Thread ... more →
hirthwork
08.07.2012 17:18
жуйк, а каково твоё мнение, количество соединений к серверу, и количество обрабатывающих их потоков, должны совпадать?
hirthwork
02.07.2012 15:53
Псач, есть один HTTP-ответ, длины которого я заранее не знаю, поэтому Content-Length я не выставляю, а Chunk Encoding писать западло. Так вот, насколько корректно просто послать FIN в конце передаваемых данных?