Issue

C compilation fails when using libfcgi as a connetor (rather than nino or cgi).

Error message

Compiling C code in C7
Compiling C code in C6
In file included from big_file_C6_c.c:16:
fc170.c: In function ‘inline_F170_2831’:
fc170.c:41: error: ‘environ’ undeclared (first use in this function)
fc170.c:41: error: (Each undeclared identifier is reported only once
fc170.c:41: error: for each function it appears in.)
Compiling C code in C5

How to reproduce

Use the "simple" example that comes with EWF and choose "simple_libfcgi" as target.

System used

EiffelStudio 7.2
OS X 10.7
gcc i686-apple-darwin11-llvm-gcc-4.2
EWF - git revision (rev: 09f32e7)

Install on OpenShift: done
Install somewhere else: ... not needed
Add a profile link to add application semantic (APLS): ?
Add queries: ?

Allow code to put content back to the client without specifying a content-length

On HTTP/1.1 this could be implemented using chunked encoding
On HTTP/1.0 .. chunked encoding is not permitted, so we could buffer the content, and send everything including computed content-length when the request processing is done.

(i.e when the system call WGI_RESPONSE.push)

I guess this could be achieved using WGI_FILTER_RESPONSE.

Adding persistent connection support to Nino .. to be HTTP/1.1
Also add pipelining support

We need to add much more tests to catch any regression or defect

See https://github.com/EiffelWebFramework/WebSocket

First this is experimentation on web socket, server side.
Then ... see how to integrate that with EWF

This could be using EiffelStudio's Wizard .. or just a command line tool.
We could even imagine using a nino based tool to provide rich Web UI interface for that.

check
https://docs.google.com/document/d/1GeHC8JcFIKdAjIlUG7_QwZ-d24SkcZV-E8T88ybQ3iY/edit

Being able to connect an OpenID provider.

So far integrated with the CMS component.

ETH student project
2 students for about 120 hours, ends january 2014

Yassin: ynh
Severin: souvarin

roadmap: https://trello.com/b/l6jVomcd/eiffel-ewf-project
repo: https://github.com/ynh/EWF and https://github.com/souvarin/EWF

The GET response has Date, Server, Content-length and Content-type. The HEAD response only has the first two.
Server is provided by Apache (this is libfcgi connector).

Debugging shows that at the time of committing the response, the WSF_HEAD_RESPONSE_WRAPPER.header has all three fields.

Perhaps this is a problem with libfcgi or Apache, rather than EWF.

Needs further investigation.

Provide an Eiffel library that abstract the notion of web api, to be able to manipulate Google API as any Eiffel library.

This is not critical, but could really help to build mashup application.

https://github.com/jvelilla/eMemcache
C wrapper, not void safe, only Linux

Need update

We could have a WSF_APP that would be easily attached to a WSF_SERVICE ... I mean mainly Router
and the idea would be to have reusable application component.

For instance we could have a WSF_USER_APP .. that would handle the login,register, reset password ... and that could be reused easily.

Integrate nino/concurrent with EWF

suspended for now due to non obvious design issue

Issue with {WSF_WGI_DELAYED_HEADER_RESPONSE} and some {WGI_FILTER_RESPONSE} such as the ..LOGGER..._RESPONSE

To follow Eiffel style, we should rename any write_ as put_

To avoid breaking code, we can use obsolete message for a period

For now router dispatch request based on

• request methods
• mapping (could be URI, URI-template, ...)

It would be convenient to have an optional condition ... that could be for instance

• Content-type checking ... if Accept is text/html for instance ...
• could also be Accept-Language ...
• and ... any condition the user could think of.

In order to generate autotests in non void-safe mode
this would be pleasant to have assertion related to attachement status.

This is useless in void-safe mode, and make the code heavier,
but in non void-safe mode, this is still valuable.

Note that only public interface would need that, no need to put such assertion in implementation feature of EWF, since EWF is regularly compiled in void-safe mode, and thus tests for such assertion.

If a client sends a header:

Accept-Encoding: gzip,deflate,sdch

(such as Google Chrome does),

then this implies identity with quality of 1.0 according to the spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3).

So CONNEG needs to treat it as such. But it doesn't.

So an application that only supports identity, incorrectly rejects such client as not acceptable.

For now, there are some default MIME handler in WSF_REQUEST
But not yet a way to change this default globally

As well as being able to close the connection within a handler (needed, for example, if streaming, and there is an error, so close connection before sending end chunk), it would be good to be able to being informed of the closure of a connection (perhaps by a callback?).

I have a specific need to manage connections to a back-end server (which does the real work). Connections to a database server might be another use case.

Provide a WSF_SERVICE dedicated to website.
That is to say ...

• handling correctly the various status code
• handling file system
• more assertions
• check document under /doc folder

We could use a specific WSF_RESPONSE that check the header is coherent as well.

Colin had idea/request about such task

check cypress library
OAuth 1 and 2 are implemented, and a few examples are provided.

https://github.com/EiffelWebFramework/cypress

building the Getting started skeleton, and make sure that each part is filled , remind assigned people.

See for instance http://www.restlet.org/documentation/2.0/tutorial

see https://github.com/EiffelWebFramework/EWF/pull/68/files#r5629615

See for instance
http://www.scalatra.org/getting-started/first-project.html

When using the policy-driven framework, the author of a handler is expected to call req.error_handler.add_custom_error in routines such as check_resource_exists. For example, if the handler handles URI templates, and not all values for a template variable are valid.

The framework generates a response using the supplied status code, but the name and message arguments are ignored - no response entity is generated.

A response entity ought to be generated using the name as a title/heading and the message as a body. This can be done automatically.

Normally the status code will be 404 or 400. I suppose it is possible that authors might use other codes that automatically generated responses won't be able to meet all SHOULDs for. I think probably that ONLY 400, 404 and 500 should be allowed in these routines, and we could add postconditions to limit the errors to these.

From RFC2616 sec 3.3
HTTP applications have historically allowed three different formats for the representation of date/time stamps:

  Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
  Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
  Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 [8](an update to RFC 822 [9]). The second format is in common use, but is based on the obsolete RFC 850 [12] date format and lacks a four-digit year. HTTP/1.1 clients and servers that parse the date value MUST accept all three formats (for compatibility with HTTP/1.0), though they MUST only generate the RFC 1123 format for representing HTTP-date values in header fields. See section 19.3 for further information.
More documentation here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3

provide Eiffel lib based on cypress to access github web api.
This should abstract the notion of OAuth ... and be simple to use.

Currently if the request input data are sent using the Transfer-Encoding: chunked we do not handle it
so either support it in the MIME handler system from WSF_REQUEST
or directly from WSF_INPUT_STREAM

I propose a new class, WSF_PROTOCOL_VERSION. And a detachable attribute of this type in WSF_REQUEST.

It will contain fields such as:

protocol: IMMUTABLE_STRING_8
major, minor: NATURAL
extension_tokens: ???

Then VERY early on in the handling of a request, req.server_protocol is parsed into one of these (and response code 506 returned if parsing fails, or it is not an HTTP protocol).

Then subsequent processing can require this is attached. And it can be used for faster checking of HTTP/1.0.

Parsing ?foo=123&bar&foobar=456

will add on foo' andfoobar' to the query parameters, and ignore `bar'

Solution: handle `bar' as empty parameters, then have foo, bar and foobar query parameters.

note: this also impact the URI template matcher code.

The following error stops the clean compile of the "simple" project when opening for the first time in Windows.

    Description Location    Position    
2   VD88: A class relies on another class with less strict void safety settings. Provider class: WSF_DEFAULT_SERVICE.   APPLICATION (simple)    10, 2   
    Error code: VD88

Configuration error: a class relies on another class with less strict void safety settings.
What to do: change void safety options so that ancestor or supplier provides higher or equal void safety.

Class: APPLICATION
Other class: WSF_DEFAULT_SERVICE
Line: 10
inherit
-> WSF_DEFAULT_SERVICE
redefine

I have double-checked each target to ensure it is set to Complete Void Safety. Not sure what is wrong.

The postcondition mime_default_set of make is in error. It should read:

mime_default_set: mime_default = a_mime

As it is, gelint issues a VWEQ error as MIME_PARSER is being compared with READABLE_STRING_8

If you have unicode variable on your system, the CGI meta variable will truncated those to ascii ...

Find solution.

Renaming

WSF_REQUEST -> SERVER_REQUEST
WSF_RESPONSE -> SERVER_RESPONSE
WSF_SERVICE -> SERVER_SERVICE

But if we start that, we should get rid of any WSF_ prefix ... here are the classes starting with WSF_

WSF_APPLICATION_X_WWW_FORM_URLENCODED_HANDLER
WSF_ERROR
WSF_FILE_RESPONSE
WSF_MIME_HANDLER
WSF_MIME_HANDLER_HELPER
WSF_MULTIPART_FORM_DATA_HANDLER
WSF_MULTIPLE_STRING
WSF_REQUEST
WSF_RESPONSE
WSF_RESPONSE_MESSAGE
WSF_SERVICE
WSF_STRING
WSF_TABLE
WSF_VALUE
WSF_VALUE_VISITOR
WSF_DOWNLOAD_RESPONSE
WSF_FORCE_DOWNLOAD_RESPONSE
WSF_HEADER
WSF_PAGE_RESPONSE
WSF_VALUE_AGENT_ITERATOR
WSF_VALUE_ITERATOR
WSF_VALUE_NULL_VISITOR

Implement client side websocket
Could be useful to build vision2 application consuming web api for instance.

Concrete case firebase web api.