http-status-code-403

Im trying do do a HEAD Object request to the S3 REST API but I keep getting a 403 Forbidden error, even though I have the policy setup with the necessary permissions on S3. The response body is empty, so I don't think its a signature problem. I've tried several changes to the policy, nothing seems to make it work. I'm able to PUT objects and DELETE objects normally, just HEAD doesn't work. Here's my bucket policy: { "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:: 999999999999:user/User" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::my-bucket" }, { "Effect":

running git instaweb in my repository opens a page that says "403 Forbidden - No projects found". What am I missing? looks like the debian install of git sets $projectroot globally in a way that confuses instaweb . I removed the $projectroot line from /etc/gitweb.conf and the error went away. I don't know Git about Git, but you're probably missing the ability to execute on the directory in question, chmod +X it. check the git-web cgi (the perl), see the directory of the projectroot is same as your currect setting. there are some settings that not in gitweb.conf Two years later .. I fixed this

I want to secure some locations in nginx by supplying deny/allow directives, but I do not want outsider to know that a location is denied. I want outsider to get 404, not 403 http code. My configuration snippet is location /admin/ { uwsgi_pass myupstream1; include /path/to/uwsgi_params; allow 127.0.0.1; deny all; } When I try to visit /admin/ nginx responds with HTTP 403, but I want it respond with HTTP 404. Any recipe for this? ARGB32 error_page 403 404 /404.html; location = /404.html { internal; #return 404 } location /admin/ { uwsgi_pass myupstream1; include /path/to/uwsgi_params; allow 127

This is mostly a philosophical question about the best way to interpret the HTTP spec. Should a directory with no directory index (e.g. index.html) return 404 or 403? (403 is the default in Apache.) For example, suppose the following URLs exist and are accessible: http://example.com/files/file_1/ http://example.com/files/file_2/ But there's nothing at: http://example.com/files/ (Assume we're using 301s to force trailing slashes for all URLs.) I think several things should be taken into account: By default, Apache returns 403 in this scenario. That's significant to me. They've thought about