Lighttpd

What happened to the edit facility?

v 1.4.26

OK, it looks like lighttpd's output was correct. It was firefox perverting it.

FF had the good idea to insert the 403 responce inside an embedded svg object. This then triggered more DOM magic by FF as it found what it inserted was not valid image/svg-xml markup, hence the error messages and screwed about content.

Sorry for thinking this was the server.

I don't seem to have the option to close this , so please feel free to do so.

BTW, it seems the 403 was due to mod_evasive. Would it be useful to send some sort of message indicating a server limit (as is common with ftp connection limits) rather than a brutal and rather obscure 403.

403 Forbidded is not really appropriate since the URL is not forbidden, it's a throttling device. I suspect replying 403 to an url that is legit maybe a spec violation.

It confused the hell out of me for a while , I'm sure it would confuse someone using the site.

I have set more suitable values to avoid this but it raised the question of whether 403 was the correct server response here.

Thanks.

lightning wrote:

FF had the good idea to insert the 403 responce inside an embedded svg object.

What content-type header was sent?

What content-type header was sent?

either it was in response to :

function refresh_svg(){
// opera object does not have svgobj.location
if ((svgobj)&&(svgobj.location)) {
if (debug) alert("before reaload "+ svgobj.location);

svgobj.location.reload(true)                                                              
  }                                                                                           
  else {                                                                                      
    if (debug) alert("full reload");                                                          
    location.reload(true);                                                                    
    // NB this breaks the repeat loop since timer obj gets reloaded.                          
  }                                                                                           
}  // end refresh_svg

This reload normally works as expected and gets the current svg from the server.

or it is from the xmlhttp response function that called refresh_svg():

function display_response() {
if (xmlhttp.readyState==4) {
// alert(xmlhttp.responseText);
refresh_svg()
document.forms⁰.elements['resp'].value=xmlhttp.responseText
}
}

this function also gets a 403 and displays it in the form as expected. Viewing the same exchange in opera I see the svg replaced by "403 forbidden" BEFORE the reload(true). This makes me think that , for some reason, the response to the xmlhttp exchange is getting inserted into the html display in both browsers. Opera does this in a way that does not create an error.

I would need to program a series of different web pages to isolate what exactly is happening.

It has cost me more time than it should to track down why I was getting a 403. I'm not sure I have a much time to work out exactly why each browser does what it does when it gets refused the page.

Since all browsers now seem to screw around with the content by DOM and js, it's rather hard to determine what they did actually receive as a response when it goes wrong.

Do you have any thoughts on whether it is legitimate to return 403 to a valid URL in this context?

lightning wrote:

What content-type header was sent?

either it was in response to :

Use (something like) Wireshark to see what was actually send, there's no need to guess.

Feature requests aside , you can't send out a header that announces compressed data then send text in rest of the packet.

Does this imply that any use of setenv.add-response-header is unsafe in anything but http 200 ? Is this an invalid use of that feature?

Is there a way to make the additional header conditional on the file being available ready to send (mod-evasive notwithstanding)?

Maybe I need a more complex config for this file type.

In fact this sort of regex matching on the URL is nothing better that file extension sniffing. Is there a way to set (or not set) the headers based on the content that is served rather than on the "file extension" of the request?

FYI:
http://www.w3.org/TR/2008/WD-SVGMobile12-20080912/conform.html#ConformingSVGServers

the encoding header seems to be the right to conform to standards. So there is a definite need for a means to add this header without it becoming a default for error condition replies as well.

Suggestions?

lightning wrote:

Does this imply that any use of setenv.add-response-header is unsafe in anything but http 200 ? Is this an invalid use of that feature?

Maybe. What's the MIME type for .svgz?
.svgz looks weird, either it's .svg with gzip content encoding or it's .svgz (.svg.gz?) without gzip content encoding.

Maybe what? Maybe bad usage or maybe setenv.add-response-header is unsafe?

mimetype.assign = (
".svg"=> "image/svg+xml",
".svgz"=> "image/svg+xml",
...
svgz is defined with the same mime type as svg. Content-Encoding , as shown in the w3.org link is gzip encoding for svgz format files. svgz is quite simply an svg file compressed with gzip.

It seems the fundamental problem here is defining a header based on the last few chars of the URL requested and not on the basis of the content returned by the server.

If client requests an image and server returns html error message, the headers must match what is sent and not what is asked for.

I think lighttpd needs to be coded to correctly respond to svgz requests without the need to artificially add this header by a manual config tweak that produces illegal output when a server error is sent.

This is a workaround for an incorrect default response but it not a stable solution as this case reveals.

There is no standard conforming way of delivering .svgz, as not all http clients have to support compression.

They don't have to support transfer compression but if the client requests svgz (or any other compressed file) that it is not capable of handling that is not an issue for the server. Most browsers have a method of dealing with content that they cannot display as long as the headers correctly reflect what is being sent. I'm sure someone of your capabilities does not need me to explain the difference.

I don't care that you can trigger bad behaviour with setenv.add-response-header,

As I have already indicated, neither do I so why do you reiterate this every time you reply?!
My problem is that I have to use this to work around the incorrect headers that lighttpd is sending.

I did not clearly understand the root of the problem when I posted the bug but thanks to icy and Olef we now have a clear description of what is happening and it is wrong.

svgz does not get sent with the correct Content-Encoding header.

</quote>
for content stored in a compressed format on the server (e.g. with the file extension "svgz"), the server must use the "Content-Encoding: gzip" or "Content-Encoding: deflate" headers as appropriate.
</quote>

Can it be any clearer than that?

Since you seem entrenched in your position that lighttpd will remain defective and not standards conformant as it claims to be, I will leave the status incorrectly set as INVALID, but don't tell me this is not a bug. It is.

Thanks for clarifying your position, and thanks to icy and Olef for helping me understand exactly what was happening.

lightning wrote:

</quote>
for content stored in a compressed format on the server (e.g. with the file extension "svgz"), the server must use the "Content-Encoding: gzip" or "Content-Encoding: deflate" headers as appropriate.
</quote>

Can it be any clearer than that?

I don't see that anywhere in a http rfc. There is one mechanism to describe the content type of files, and it is content-type. serving precompressed files with content-encoding is an optimization, and not supporting it is certainly not a bug.

It's probably a feature request to set more headers than just Content-Type based on file extension. Content-Encoding, but Content-Language and others come to mind.

Your problem is basically that lighty should perform an additional check if the file is available. For static files this can easily be done with a small lua-script, which checks if a file is present and sets the header accordingly. If not, it produces a 404 without content headers.

That content-encoding.lua looks like:

attr = lighty.stat(lighty.env["physical.path"])
if (attr) then
  lighty.header["Content-Encoding"] = "x-gzip" 
  else
   return 404
end

$HTTP["url"] =~ "\.svgz$" { magnet.attract-physical-path-to = ( "/path/to/content-encoding.lua" }

If a file needs more then content-type set to make a browser happy, its already faulty imho. Chrome, Safari, Opera, fx - they all handle this kind of files differently and there´s a list of bugs filed already. Please check yourself if this quick hack makes every browser happy or breaks others now.

I agree with stbuehler, that svgz needs an encoding too is not a lighty bug.

Olaf-van-der-Spek wrote:

It's probably a feature request to set more headers than just Content-Type based on file extension. Content-Encoding, but Content-Language and others come to mind.

I might agree. For upcoming lighty2 we should consider this and make it easier to include, but i doubt this features goes into 1.x. For static files we have lua, for dynamic stuff you´d need to set it yourself.

nitrox wrote:

For upcoming lighty2 we should consider this and make it easier to include

No "should", already possible :)