Expires header not updated when status 304

Discussion in 'Install/Configuration' started by eduardorochabr, May 25, 2007.

  1. eduardorochabr

    eduardorochabr New Member

    I've noticed that LSWS does not send Expires header in 304 responses, so the browser always uses the old Expires. Shouldn't the Expires be updated?

    Use case:

    1. First page visit

    get /default.css
    response: 200, Expires: 25-May-2007 18:00

    2. Page visit before expires

    (nothing, since browser cached)

    3. Page visit after expires

    get /default.css
    response: 304, etag: '34-342342-2342'

    ALL consecutives page visits make the browser request the resource again, based on old Expires.
  2. mistwang

    mistwang LiteSpeed Staff

    Fix will be in 3.1.2 release.
  3. eduardorochabr

    eduardorochabr New Member

    Great news! Thanks!
  4. mistwang

    mistwang LiteSpeed Staff

  5. eduardorochabr

    eduardorochabr New Member

    It works, thanks!

    However, I have a question. I tested with the Example virtual host, setting image expires to a short time. It worked perfectly, but I didn't get why "index.html" gets cached, do you know why? Just curious.

    Will it be available via update, link 3.1.1?

    Thanks once again.
  6. mistwang

    mistwang LiteSpeed Staff

    It is up to the browser to cache or not to cache a html page unless you have cache control header in the reply.

    It will be available via update, we still need working on some features.
  7. eduardorochabr

    eduardorochabr New Member

    Reinstall

    Hi mistwang,

    How could I reinstall this version in production smoothly? Is there a way?

    If I just reinstall it using the same values, like users and directories, it would be OK? I mena, it would use the same settings as before?

    Thanks.
  8. mistwang

    mistwang LiteSpeed Staff

    Yes, just run the install.sh, then select "upgrade", your current configuration will not be touched.
  9. eduardorochabr

    eduardorochabr New Member

    403

    Hi mistwang,

    I've just upgraded a production server to this version, and the main URL of the site gets a 403, like "http://www.example.com/".

    The previous version was 3.1.1-std, and when I switch back it works without problem.

    Any idea?

    Thank you.
    Last edited: Jun 1, 2007
  10. mistwang

    mistwang LiteSpeed Staff

    Do you have any request filter rule configured? Maybe turning on "Debug logging" by set "Debug Level" to "High" will help.
  11. eduardorochabr

    eduardorochabr New Member

    Hi mistwang,

    I did what you suggesting, set DEBUG level to HIGH. I have no request filter rule configured. The difference I can see is in return code ("24" from 3.1.2 and "25" from 3.1.1). However, the only URI with this problem is "/", all other URI's work without problems.

    3.1.2

    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1] HttpIOLink::handleEvents() events=1!
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1] HttpConnection::eek:nReadEx(), state: 0!
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1] readToHeaderBuf().
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1] Read from client: 769
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1] read 769 bytes to header buffer
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1] processHeader() return 0, header state: 3.
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1] readToHeaderBuf() return 0.
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1#orkurioso] New request:
    Method=[GET], URI=[/],
    QueryString=[]
    Content Length=0
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1#orkurioso] Find context with URI: [/], location: [.../orkurioso/current/public/]
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1#orkurioso] Index file is not available in [.../orkurioso/current/public/]
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1#orkurioso] processContextPath() return 24
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1#orkurioso] processNewReq() return 24.
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1#orkurioso] HttpConnection::sendHttpError(),code=403 Forbidden
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1#orkurioso] HttpConnection::flush()!
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1#orkurioso] Written to client: 628
    2007-06-02 05:48:36.956 [DEBUG] [189.6.22.180:2826-1#orkurioso] HttpConnection::nextRequest()!
    2007-06-02 05:48:41.356 [DEBUG] [189.6.22.180:2826-2] Keep-alive timeout, close!
    2007-06-02 05:48:41.356 [DEBUG] [189.6.22.180:2826-2] Close socket ...

    3.1.1:

    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0] HttpIOLink::handleEvents() events=1!
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0] HttpConnection::eek:nReadEx(), state: 0!
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0] readToHeaderBuf().
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0] Read from client: 769
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0] read 769 bytes to header buffer
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0] processHeader() return 0, header state: 3.
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0] readToHeaderBuf() return 0.
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0#orkurioso] New request:
    Method=[GET], URI=[/],
    QueryString=[]
    Content Length=0
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0#orkurioso] Find context with URI: [/], location: [.../orkurioso/current/public/]
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0#orkurioso] Index file is not available in [.../orkurioso/current/public/]
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0#orkurioso] processContextPath() return 25
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0#orkurioso] processNewReq() return 25.
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0#orkurioso] HttpConnection::sendHttpError(),code=404 Not Found
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0#orkurioso] redirect to:
    URI=[/dispatch.lsapi],
    QueryString=[]
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0#orkurioso] Find context with URI: [/dispatch.lsapi], location: []
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0#orkurioso] processContextPath() return 0
    2007-06-02 05:53:35.260 [DEBUG] [189.6.22.180:2938-0#orkurioso] run lsapi processor.
    2007-06-02 05:53:35.260 [DEBUG] [uds://tmp/lshttpd/orkurioso:_.sock] create new connection succeed!

    Thank you.
    Last edited: Jun 11, 2007
  12. mistwang

    mistwang LiteSpeed Staff

    That's because no index file is available, and autoindex is off, before, it returns 404 not found, but another user said, Apache return 403, so we change it to match Apache behavior.
  13. eduardorochabr

    eduardorochabr New Member

    Hi, mistwang.

    It works like this only to ROOT URI? Why doesn't behave this way for something like example.com/start/?

    Actually, I see many Rails applications being broken with this upgrade, like mine. I can't see a straightforward solution besides using a Rewrite, is this the way to go?

    Thank you.
  14. mistwang

    mistwang LiteSpeed Staff

    Sorry, I forgot Rails dispatcher rely on 404 handler when I made the change. Need to find a way to make both side happy. :)

Share This Page